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

[Germán Arias]

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