In reply to Stefan Seefeld <[EMAIL PROTECTED]>
>> with psv i have to (a) dump the page contents to ghostscript, which
>> is reasonably fast, (b) wait for ghostscript to process the page,
>> and (c) get the page back. step (c) kills everything - as you can
>> see - because loading the big page description takes time. step (b)
>> is also slower than it could be because it generates a big page
>> description that would otherwise be unecessary. if there was a
>> `ggi' driver for ghostscript, then things would be much faster,
>> because step (c) would be eliminated, and step (b) could then be
>> made much more efficient.
>
>so how do you do (c) ? Are you asking gs to write to a bitmap (png,
>say) and then load that (via file or pipe) into your process ?
hi stefan,
yes, i ask gs to write to a pgm and load it via a pipe. it takes quite
a while (1 second or so) for an 800x600 screen (=800k pgm), and it
takes quite a while for gs to render the page.
>Having never looked into gs code I don't know how difficult it would
>be, but it appears that the natural thing to do would be to write a
>'ggi target' for it, i.e. to let gs render directly into a ggi
>visual.
that would be the ideal situation, but would require modifying gs
itself. i don't have time for that, but it's a more than worthwile
goal.
>It might be interesting to tell him about your goal, i.e. to have a
>ghostscript driver targetted at ggi. Who knows, may be he'd be
>willing to help. It shouldn't be difficult. After all a visual is
>just a specification for a particular memory layout...
i think having gs to get to know ggi is a worthwile goal for the ggi
project itself. isn't somebody willing to try?
--
Cesar Augusto Rorato Crusius __o __o __o __o __o
Stanford University _`\<, _`\<, _`\<, _`\<, _`\<,
e-mail:[EMAIL PROTECTED] (_)/(_) (_)/(_) (_)/(_) (_)/(_) (_)/(_)
www.stanford.edu/~crusius
o _ _ _
__o __o __o __o /\_ _ \\o (_)\__/o (_)
_`\<, _`\<, _`\<, _`\<, _>(_) (_)/<_ \_| \ _|/' \/
(_)/(_) (_)/(_) (_)/(_) (_)/(_) (_) (_) (_) (_)' _\o_
He who sacrifices functionality for ease of use
Loses both and deserves neither