GNOME Bugzilla – Bug 410442
gdkdrawable-quartz.c doesn't compile
Last modified: 2007-04-03 18:58:31 UTC
Please describe the problem: Line 64 of gdkdrawable-quartz.c doesn't compile with the latest cairo. The definition of cairo_quartz_surface_create() has changed. Line 64 needs to be replaced with: cairo_public cairo_surface_t * cairo_quartz_surface_create_for_cg_context (CGContextRef cgContext, unsigned int width, unsigned int height); Steps to reproduce: 1. 2. 3. Actual results: Expected results: Does this happen every time? Other information:
Created attachment 83048 [details] [review] one line fix
Does that make it work though? I would have guessed we will need a lot of adoptions in gdk since the "flip hack" has been removed from cairo.
Oh, I don't know about that. I just went into the cairo headers and pulled the likeliest looking function to replace it with.
I just tried it and while it builds, it doesn't work. We will have to go through basically the whole backend now and fix it up to work with the new backend. It's a bit of an effort, but it will pay off long-term. First of all we need to come up with a solution for the coordinate system problem (cocoa views have their origin at the bottom, not the top as X e.g. The old cairo backend had a bad hack that made it possible to just flip the y coord, so the problem was kind of worked around. Now we need to fix it for real in the gdk backend instead). I suspect that we also will need to rethink parts of the expose/draw handling too, if nothing else just to improve the performance a bit.
Can't subclasses of NSView easily be flipped to use the top left coordinate system? Or is that too lowlevel? http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/Classes/NSView_Class/Reference/Reference.html#//apple_ref/occ/instm/NSView/isFlipped
I don't think it's as simple as that (we currently have the view flipped, which is why the hack was needed in cairo), so that the coordinate system matches the one gdk uses. I haven't thought this through properly yet, but my guess is that we will have to handle the flipping ourselves now instead. There is actually some of that already in the event handling, since coordinates relative the screen are not flipped, so this thing will probably make the code more consistent :) Any ideas here are much appreciated.
Well, the motivation when removing the hack from cairo was that we thought all cairo surfaces should have the same coordinate system, that is, origin at top left. So you are saying that the quartz backend now has the origin in bottom left? That's not what it was supposed to be. CCing Carl.
(In reply to comment #4) > I just tried it and while it builds, it doesn't work. > > We will have to go through basically the whole backend now and fix it up to > work with the new backend. It's a bit of an effort, but it will pay off > long-term. First of all we need to come up with a solution for the coordinate > system problem (cocoa views have their origin at the bottom, not the top as X > e.g. The old cairo backend had a bad hack that made it possible to just flip > the y coord, so the problem was kind of worked around. Now we need to fix it > for real in the gdk backend instead). All the flip hack ever did was just invert the resulting image before painting it to the destination after the fallback code took place. The old Quartz backend didn't really describe what y_grows_down did (e.g. did it mean "This cgcontext has y growing downward" or "I want this surface to have y growing downward, even though the cgcontext does not" -- I believe it meant the former). With the new code, if you have a CGContext in the Quartz coordinate space, then you have to flip the coordinate space yourself (as is in the docs): CGContextTranslateCTM (cgContext, 0.0, height); CGContextScaleCTM (cgContext, 1.0, -1.0); surface = cairo_quartz_surface_create_for_cg_context (...); Now, looking at GdkQuartzView, it's returning YES from isFlipped, so I'm not sure why the drawing is upside down -- your entire view should be in the QuickDraw (top-left) coordinate space, and Quartz should apply the above transform for you before calling drawRect. Just to make sure -- is the drawing actually showing up upside down? Or is nothing drawn at all?
Some gdkwindow backgrounds are cleared to their background color but no text and no foreground is drawn.
An update, things are actually working, more or less, except that things are really really slow. We are probably abusing cgcontext/cairo surface a bit. I see some weird errors when using clearlooks (when it calls cairo_fill, there is a UNSUPPORTED error somewhere in the stack that triggers an assertion in cairo). I'll start by trying to see what we are doing wrong to cause that severe slowness.
A small update on this, I have investigated why the new cairo quartz surface is so slow when used by GTK+. One reason is that the surface calls CGContextFlush when the surface is finished. In a typical GTK+ app, like gtk-demo, just starting it creates and detroys ~20 surfaces, and moving the mouse across it creates and destroys 20 more. With the old surface, GTK+ itself could control when the flushing was done, and that level of control is not possible currently with the new surface. Vladimir, do you think it would be possible to either leave it up to the user code completely to handle flusing, or be able to disable flushing per surface?
OK, looks like cairo quartz now doesn't flush, nice :) I will finish up my patch to gdk ASAP and commit (not today probably).
Fixed in SVN now, updated to work with the new cairo surface API.
*** Bug 425944 has been marked as a duplicate of this bug. ***