Re: WIN32Server don't display the auto-completion window

[Fred Kiefer]

Thank you for reverting. You are correct that switching the backing style is 
only a tiny waste of graphics memory. We could change all windows to 
NSBackingStoreRetained, but if we did we wouldn't know whether the other styles 
still work and if user code uses a different type, that could fail.

Ignoring the style in the backend is different, it wastes just the same memory, 
but does so consistently. The problem here is why this doesn't work for you. I 
am sure it used to work for both winlib and cairo. And I really cannot see, 
what is causing the problem for you with cairo. Please try to find the issue in 
back, the code there already should ignore the backing style, why isn't it?

Fred

On the road

Am 24.02.2015 um 00:59 schrieb Germán Arias <address@hidden>:

> El lun, 23-02-2015 a las 23:01 +0100, Fred Kiefer escribió:
>> Could you please take back the gui changes you commited to work around this 
>> issue? I really don't think that this is a gui issue and we should try to 
>> address it on the correct level. In this case it would be in back and there 
>> in the win32 code. If you have a look there in WIN32Server.m you will see 
>> that for the cairo backend none of the backing store type settings should 
>> have any effect as all that code is just conditionaly for winlib. The 
>> question now should be why this doesn't have the intended effect for you.
>> 
>> Fred
>> 
>> On the road
> 
> Done. But I don't see a problem using buffered windows. According with
> this:
> 
> https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Class/#//apple_ref/c/tdef/NSBackingStoreType
> 
> NSBackingStoreNonretained
> 
> The window draws directly to the screen without using any buffer. You
> should not use this mode. It exists primarily for use in the original
> Classic Blue Box. It does not support Quartz drawing, alpha blending, or
> opacity. Moreover, it does not support hardware acceleration, and
> interferes with system-wide display acceleration. If you use this mode,
> your application must manage visibility region clipping itself, and
> manage repainting on visibility changes. 
> 
> And:
> 
> NSBackingStoreRetained
> 
> The window uses a buffer, but draws directly to the screen where
> possible and to the buffer for obscured portions. You should not use
> this mode. It combines the limitations of NSBackingStoreNonretained with
> the memory use of NSBackingStoreBuffered. The original NeXTSTEP
> implementation was an interesting compromise that worked well with fast
> memory mapped framebuffers on the CPU bus—something that hasn't been in
> general use since around 1994. These tend to have performance problems.
> In OS X v10.5 and later, requests for retained windows will result in
> the window system creating a buffered window, as that better matches
> actual use. 
> 
> And NSBackingStoreBuffered is the recommendation "The window renders all
> drawing into a display buffer and then flushes it to the screen. You
> should use this mode. It supports hardware ...."
> 
> On the other hand, the problem with tooltips is not only my problem.
> See:
> 
> http://lists.gnu.org/archive/html/bug-gnustep/2015-02/msg00002.html
> 
> I think we also should offer solutions for end users. Allow tooltips
> automatically displays views is not a big deal. I tested this on
> GNU/Linux and I don't see any difference. Just that this works on
> Windows.
> 
> Just my thoughts.
> 
> Germán.
> 
> 
> 
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev