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 Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev