Slowness when using interface in fullscreen mode #46993

New Issue

Dewi BORDAGE · 2015-12-16T11:03:12+01:00

Dewi BORDAGE commented

2015-12-16 11:03:12 +01:00

System Information

MacBook Pro memory 8 GB
OS X El Capitan (10.11.2)
Graphics : Intel Iris Graphics 6100

Blender Version

2.76b (current)
tested with an older version : 2.73a -> same issue

Short description of error

Example of scene : startup scene with a cube at the center
Everything is fine on OS X window mode. When switching to OS X fullscreen mode, navigation in 3d view becomes extremely slow. When changing view with trackpad or emulated numpad, display gets refreshed after several seconds.

**System Information** MacBook Pro memory 8 GB OS X El Capitan (10.11.2) Graphics : Intel Iris Graphics 6100 **Blender Version** - 2.76b (current) - tested with an older version : 2.73a -> same issue **Short description of error** Example of scene : startup scene with a cube at the center Everything is fine on OS X window mode. When switching to OS X fullscreen mode, navigation in 3d view becomes extremely slow. When changing view with trackpad or emulated numpad, display gets refreshed after several seconds.

Dewi BORDAGE commented

2015-12-16 11:03:12 +01:00

Changed status to: 'Open'

Dewi BORDAGE commented

2015-12-16 11:03:12 +01:00

Added subscriber: @Dewi

Bastien Montagne commented

2015-12-16 20:59:10 +01:00

Added subscribers: @MartijnBerger, @brecht, @ThomasDinges

Julian Eisel commented

2015-12-22 22:00:59 +01:00

Added subscriber: @JulianEisel

Julian Eisel commented

2015-12-22 22:00:59 +01:00

Can somebody with a Mac confirm this?

Dewi BORDAGE commented

2015-12-28 19:04:59 +01:00

Something new : I have not faced the issue when I used an external display. That is to say, with the same configuration as in the description and in OS X fullscreen mode on the external display, everything was fine.

Sergey Sharybin commented

2015-12-30 11:13:34 +01:00

Added subscribers: @MikeErwin, @sebastian_k, @Sergey

Sergey Sharybin commented

2015-12-30 11:13:34 +01:00

@sebastian_k, @brecht, @MikeErwin, can you test the issue?

Julian Eisel commented

2016-01-04 16:27:31 +01:00

Common guys, that's weak!

Brecht Van Lommel commented

2016-01-07 21:53:13 +01:00

I can confirm the issue, using the same Intel Iris Graphics 6100.

It's not so much slow as there is a lag where e.g. menus don't draw properly until you move the mouse. The only Window Draw Method that appears to work correctly is Full, which is more of a debugging mode. As if OpenGL swapping isn't work correctly somehow.

I can confirm the issue, using the same Intel Iris Graphics 6100. It's not so much slow as there is a lag where e.g. menus don't draw properly until you move the mouse. The only Window Draw Method that appears to work correctly is Full, which is more of a debugging mode. As if OpenGL swapping isn't work correctly somehow.

Brecht Van Lommel self-assigned this 2016-01-07 21:53:26 +01:00

blender-admin commented

2016-01-07 23:51:38 +01:00

This issue was referenced by cd6c6ee1a5

This issue was referenced by cd6c6ee1a54ec0eed33592bcb7e499ce5141d4ac

Brecht Van Lommel commented

2016-01-07 23:53:34 +01:00

Changed status from 'Open' to: 'Resolved'

Brecht Van Lommel closed this issue

2016-01-07 23:53:34 +01:00

Brecht Van Lommel commented

2016-01-07 23:53:34 +01:00

It's indeed related to swapping. It seems like a driver bug because I can't find a good explanation for why it would fail.

When drawing in fullscreen, graphics drivers often do an optimization where instead of copying (part of) the front buffer to the back buffer, they simply swap the pointers to the buffers to avoid doing a copy altogether. The default triple buffer drawing should work whether or not the driver does this optimization, but it seems to somehow fail here.

The workaround I found is to disable this code. I'm guessing this driver code path isn't tested as well and so might have a bug.

*Guarantees the back buffer contents to be valid after a call to NSOpenGLContext object's flushBuffer* needed for 'Draw Overlap' drawing method
attribs.push_back(NSOpenGLPFABackingStore);

Removing this breaks overlap drawing, but triple buffer is the default on Mac and works fine as far as I know. We will eventually remove overlap drawing anyway, probably in Blender 2.8.

It's indeed related to swapping. It seems like a driver bug because I can't find a good explanation for why it would fail. When drawing in fullscreen, graphics drivers often do an optimization where instead of copying (part of) the front buffer to the back buffer, they simply swap the pointers to the buffers to avoid doing a copy altogether. The default triple buffer drawing should work whether or not the driver does this optimization, but it seems to somehow fail here. The workaround I found is to disable this code. I'm guessing this driver code path isn't tested as well and so might have a bug. ``` *Guarantees the back buffer contents to be valid after a call to NSOpenGLContext object's flushBuffer* needed for 'Draw Overlap' drawing method attribs.push_back(NSOpenGLPFABackingStore); ``` Removing this breaks overlap drawing, but triple buffer is the default on Mac and works fine as far as I know. We will eventually remove overlap drawing anyway, probably in Blender 2.8.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Slowness when using interface in fullscreen mode #46993