[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSColor patterns and NSImage draw...
From: |
Uli Kusterer |
Subject: |
Re: NSColor patterns and NSImage draw... |
Date: |
Mon, 01 Nov 2004 16:19:53 +0100 |
User-agent: |
MT-NewsWatcher/3.4 (PPC Mac OS X) |
In article <mailman.6589.1099314122.2017.discuss-gnustep@gnu.org>,
Fred Kiefer <fredkiefer@gmx.de> wrote:
> As for pattern colours, Alexander and I discussed this some time ago. My
> idea was a cheap implementation on the GSC level (common layer of the
> backends), where we would add the image as an ivar on the GState and
> when performing a fill operation use this value, if available, instead
> of the colour values (Setting a colour would unset the image of course).
> For the image than the normal draw operations, plus the clippath would
> be used.
Fred,
yeah, that was the first idea that entered my mind as well. But when I
looked at the sources I was quickly cured of the thought of just going
in and implementing that, because the backend is rather complex. I have
no idea where the drawing is actually taking place (or should be, as the
case is).
> (Lots of interesting stuff snipped)
> Again any solution here would require a parallel
> change to GUI and all backends.
Couldn't you have something like Quickdraw's bottlenecks that allows
gracefully degrading functionality on older backends? Quickdraw had a
"QDProcs" data structure which contained pointers to functions for
various drawing operations, which could be replaced (e.g. printer
drivers installed their own functions in a drawing context which
performed output to the printer instead of the screen).
Then all that's needed would be to check whether one of these functions
is NULL. If it is, either do nothing, or fall back on a near-match (e.g.
instead of drawXXX we'd just use compositeXXX or dissolveXXX, which at
least shows the image, even if it ignores transformations).
Don't the DPS functions already have something vaguely like that? I
mean, they seem to be directly calling the functions behind an object's
methods in a very weird and low-level way. Couldn't a
respondsToSelector: be used to find out whether the backend supports the
new stuff?
Intriguing stuff,
-- Uli
http://www.zathras.de