Can cairo_set_user_data help with this in anyway? Like using it to store additional gs states to cairo state. I am not sure what I am talking about and I barely remember what I've done.
On Tue, Jun 14, 2011 at 4:19 AM, Fred Kiefer <[email protected]> wrote: > In principle you are correct but we need to look out for a few more calls > like GSDefineGState and DPSsetgstate. These get used to store and set the > GState for a window or view. Here we really need a copy of the current > state. > > I just scanned through the code in GSContext.m and it looks like we could > try to replace the two methods DPSgsave and DPSgrestore in cairo with the > native functions and could get away with it. But I am really not sure. The > last time I tried this horribly failed for scrolling, but I cannot remember > the details of this. > > Fred > > On 13.06.2011 22:39, Eric Wasylishen wrote: >> >> What I'd like to do is have DPSgsave and DPSgrestore use cairo_save and >> cairo_restore directly, and only go to the trouble of trying to set the >> cairo gstate using the GNUstep gstate data when one of the unusal ops like >> DPScopy: or DPSexecuserobject: are used. >> >> --Eric >> >> On 2011-06-13, at 1:37 PM, Fred Kiefer wrote: >> >>> On 13.06.2011 20:19, Quentin Mathé wrote: >>>> >>>> Le 13 juin 2011 à 14:41, Fred Kiefer a écrit : >>>> >>>>> I had to restrict the usage of .the new image drawing mechanism for >>>>> the cairo backend to the cases where the clipping region is >>>>> representable as a list of rectangles. With the new drawing code we >>>>> store and restore the GState and this only works correctly when the >>>>> clipping region is composed of rectangles. >>>> >>>> I don't see where the gstate is saved/restored in the new drawing >>>> code and not in the old code path. I checked both Back and Gui. >>>> Which lines are you referring to precisely? In Back cairo_save() and >>>> cairo_restore() seems to be used in both cases. On the Gui side, >>>> PSgsave(), DPSgsave(), PSgrestore() or DPSgrestore() seems to be used >>>> in the same way in the two drawing methods. >>>> >>>>> The problem became obvious in the JigSaw Application which is now >>>>> part of GAP and which does use non-rectangular shapes for its >>>>> pieces. These pieces where drawn incorrectly with the new drawing >>>>> mechanism but correctly with the old one. >>>> >>>> Are they drawn correctly on Mac OS X? >>>> >>>>> I would love to see a better solution for this, so feel free to >>>>> suggest one. >>>> >>>> Agreed :-) >>> >>> Quentin, >>> >>> I would have expected a little trust in my analysis here :-) >>> But anyway you are free to ask and not just take my word for it. The >>> difference is between the methods guiDrawInRect:... and >>> nativeDrawInRect:... If you carefully count the PSgsave calls you will >>> see that each has exactly one in each call path. The difference is that >>> in guiDrawInRect:.. the save happens while drawing on the cache surface >>> whereas for nativeDrawInRect:.. we use the save while drawing on the >>> main surface. This may look only slightly different but changed the whole >>> thing. >>> >>> The annoying bit here is that we now know that we have a general problem. >>> For this image drawing issue I was able to resolve it, but if somebody >>> manually sets a non rectangular clip and than uses PSsave we are in trouble. >>> >>> Fred > > > _______________________________________________ > Gnustep-dev mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev > -- .----. Bluna Ratimonkey /.../\...\ 漫画家 |.../ \...| http://qstx.blogspot.com (Free Software Advocacy & Development) |../ \..| http://feedbat.blogspot.com (Studio Work For Hire) \/ \/ http://groundzerostudiocomplex.blogspot.com (Studio Research) _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
