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

[Quentin Mathé]

Hi Eric and Fred,

Le 4 juil. 2011 à 23:07, Eric Wasylishen a écrit :

>> I had a quick look into these new methods and didn't like too much what I 
>> saw there.
> 
> I agree. It's a real mess.
> 
> The positive thing is that most of the rest of NSImage is pretty tidy, and 
> all drawing goes to -drawInRect:..., so we just need to fix that one method 
> :-).

Yes. I remember I had bad experiments when I started to touch this code, so I 
let it as is.

>> We have a lot of code duplication between these two methods, but we also 
>> have differences there which I don't understand. Why do we use scaling for 
>> the native drawing but not for the gui drawing?
> 
> Not sure, what do you mean by scaling? btw, my ImageSelectionTest in GSTest 
> currently lacks a test of the effect of setting a transformation matrix / a 
> NSView bounds transform before drawing an image, and that needs to be added. 
> The test should be renamed to ImageDrawing-test since it's turning in to a 
> general test of image drawing.

It's going to be hard to completely merge the two code paths, because the new 
code path implies the backend supports negative scaling (that's mostly why the 
gui drawing doesn't use scaling). Xlib don't support that. For such a backend, 
it means NSImage has to approximate the flipping result and ask the backend to 
draw the image in a custom location, rather than the one based on the current 
coordinates and CTM.

The Art backend could be corrected, but the code is very convoluted, so I have 
no idea whether it's possible without a major rewrite or not. I also tried to 
fix the GDI backend to use the new code path, because this backend code is much 
easier to understand, but I gave up because it wasn't so easy in the end. I 
don't recall which problems I encountered exactly.

It's important to remember the gui drawing works around various bugs in Xlib, 
GDI and Art backends, and these bugs are not the same in each backend… which 
makes rewriting this gui drawing quite tricky.

As a side note, I'm not sure there is a real interest in supporting the Art 
backend in the next GNUstep releases. Unless I overlook some real use case, I'd 
suggest to deprecate it. We have Cairo currently which does the same but much 
better. It looks to me that nowadays people uses either Cairo, GDI or Xlib.

For the record, here is the bug report where I introduced the two code paths 
and below I pasted what I wrote about these code paths:

https://savannah.gnu.org/bugs/?27782

> For -drawInRect:, we have now two code paths. The old one that handles the 
> scaling in Gui but has several issues: 
> - draw at the wrong location in flipped coordinates 
> - draw at the wrong location when there is a scaling with inRect and fromRect 
> - is slow when you want to draw a small image portion with a scaling or 
> rotation involved. 
> 
> And a new Cairo-specific code path much simpler that corrects all the 
> previous issues. 
> 
> Ultimately it is probably possible to reimplement -compositeGState on top of 
> -drawGState, but since the semantic differences are pretty important I don't 
> think it really matters that much. It was also easier to debug and to figure 
> out where the bugs really were once I introduced a distinct code path for 
> -drawInRect. 
> It's probably far from ideal, but when you consider the number of issues (or 
> changes required in each backend) and the fact we'll probably switch to Opal 
> in the long run, it sounds acceptable to me. 

Cheers,
Quentin.