Hey Fred, David, I haven't had much time to work on GNUstep in the past few months but just want to say I will try to help out with this!
For gstates, if I understand the semantics correctly, we can use the code from our cairo backend for copying and restoring the graphics state to/from an object, but only when the user does explicit save/restore. For normal pushes/pops, we can just use the current opal implementation which is basically a cairo_save/cairo_restore with a bit of extra bookkeeping. Regards, Eric On 2013-02-02, at 3:46 PM, Fred Kiefer <fredkie...@gmx.de> wrote: > Sounds like a plan we all agree on. I will make the DPS changes next week and > then start to work on the Opal bavkend together with Ivan. There are two open > issues I know about, font handling and stored gstates. For both we need a > solution before that backend is fully working, the rest should be fairly > simple. > > Fred > > On the road > > Am 02.02.2013 um 07:48 schrieb David Chisnall <thera...@sucs.org>: > >> On 1 Feb 2013, at 16:55, Ivan Vučica wrote: >> >>> Moving to an Opal backend and then making the graphics context available >>> via -[NSGraphicsContext graphicsPort] would be something I wouldn't oppose >>> in any way. I wonder why ;-) >>> >> >> Using the CoreGraphics API as our back end interface is definitely something >> that I would support in the medium to long term, but it requires a fair bit >> of work. Just changing the DPS functions to CGFloat for now and getting an >> Opal back end that uses the CoreGraphics APIs would be a good start. >> >> David >> >> -- Sent from my Apple II >> > > _______________________________________________ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
