The problem with cairo backend is that, if the window is not buffered, The line:
copy->_ct = cairo_create(cairo_get_target(_ct)); at method -copyWithZone, fails with the error CAIRO_STATUS_NO_MEMORY. Or maybe this is a bug with NSZone on Windows? I don't know but with buffered windows there is no problem. With winlib I don't know what is the problem. But I think cairo will be the default backend on the future. Because maintain two backends will be a nightmare. Germán El mar, 24-02-2015 a las 09:22 +0100, Fred Kiefer escribió: > 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 <[email protected]>: > > > 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 > > [email protected] > > https://lists.gnu.org/mailman/listinfo/gnustep-dev > > _______________________________________________ > Gnustep-dev mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
