[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #21229] Gorm cannot load GormDocument.gorm because cairo backend do
[bug #21229] Gorm cannot load GormDocument.gorm because cairo backend does not implement DPSshfill
Fri, 05 Oct 2007 13:54:41 +0000
Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.5 (like Gecko)
Update of bug #21229 (project gnustep):
Item Group: Bug => Change Request
Follow-up Comment #1:
I don't quite understand what you are complaining about. Is it that the cairo
(as well as the xlib and the windows) backend don't implement the DPSshfill:
method or is it that Gorm wont load a NIB because of this?
As you put this in as a backend bug, most likely the later is the case. Now
what is the DPSshfill: method? It is an extension specially there in the art
backend. It is based on the Postscript shfill operator, but takes a function
dictionary as input instead of a shading dictionary as a proper shfill
I had a quick go on the code and it would be easy to move the implementation
of the function itself up into gsc. The problematic part here is that the
shfill operator works on the clip area. The art backend is the only backend
where we have direct control over the clip path. In the other backends we pass
on the clip path to the underlying drawing system and forget about it. This
means, we are not able to easily fill the clip path with the result of the
We could of course fill the whole result area with the function and clipping
would take care of not changing anything outside the allowed range, but this
is a wasting of drawing time.
Another solution would be to abanden the DPSshfill method and find out, what
it was used for and replace this with an operation that is easy to implement
on most backends. I would expect that people used this method to implement
colour gradients and there are better ways to get the same result.
What does your application use it for?
Reply to this item at:
Nachricht geschickt von/durch Savannah