gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSImage drawing (was Re: Problem with Gorm)


From: Fred Kiefer
Subject: Re: NSImage drawing (was Re: Problem with Gorm)
Date: Tue, 05 Jul 2011 09:40:46 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.17) Gecko/20110414 SUSE/3.1.10 Thunderbird/3.1.10

On 04.07.2011 23:07, Eric Wasylishen wrote:
I think that we should start a discussion about this whole drawing code. 
Hopefully we end up with a deeper understanding of what should happen here and 
will then be able to package it up with a nice and clean call to the backend 
and three or four (almost?) correct implementations for this in GSContext, 
GSStreamContext and GSCairoContext. But then I may be completely wrong here, as 
I really don't understand much of this new code.

What I would like to do is:

- get rid of -guiDrawInRect entirely.
- reinstate caching since currently there is no caching whatsoever.
- possibly switch to the new 
drawInRect:fromRect:operation:fraction:respectFlipped:hints: method

Our goal should be for the following cairo calls to be used when drawing an 
uncached image:

cairo_surface_t *src = cairo_image_surface_create(CAIRO_FORMAT_ARGB32, [rep 
pixelsWide], [rep pixelsHigh]);
// copy the ARGB data in NSBitmapImageRep to the src image surface in BGRA 
format
cairo_t *cr = cairo_create(dest);
// set the transformation matrix and clipping rect on cr to refect the source 
rect and dest rect
cairo_set_source_surface(cr, src, 0, 0);
cairo_paint(cr);
cairo_destroy(cr);
cairo_surface_destroy(src);

That's it, I think.  To do caching, the code is the same except the 'src' 
surface is created as an xlib surface so it's stored on the X server, and the 
surface is kept around and reused, so the copying from NSBitmapImageRep to 
cairo only happens once as long as the cached surface is kept alive.

What you are talking about is to combine the current code in CairoGState -DPSimage:... and drawGState:... into one method. Or rather to split up the code differently, having one method that creates an image surface and different ways to draw that. This sounds sensible to me, we just need to be aware that sometimes we are already dealing with cached images that that we need a code path for that as well.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]