Re: Canvas shortcomings
- From: Owen Taylor <otaylor redhat com>
- To: Lauris Kaplinski <lauris ximian com>
- Cc: Havoc Pennington <hp redhat com>, Gustavo João Alves Marques Carneiro <ee96090 fe up pt>, gnome-devel-list gnome org
- Subject: Re: Canvas shortcomings
- Date: 17 Jun 2001 14:16:53 -0400
Lauris Kaplinski <lauris ximian com> writes:
> Hello!
>
> Unreachable goal IMHO :(
> I have not yet find a way to make a graphic API, that:
> 1) has reasonable speed and quality
> 2) can be used for both interactive and output graphics
> 3) has single, consistent API
>
> If anybody knows the solution, I would be very interested.
Well, I think you have to define the parameter space a bit for
"reasonable speed and quality". If you want perfect glyph positioning
at all resolutions and PDF-1.4 compositing, then you probably aren't
going to get wonderful speed.
But shooting a little lower, I think its not that hard to come up with
a good compromise.
I'd imagine something like:
- Primitives are glyphs and bezier shape objects
- A set of standard shape objects like circle, rectangle,
etc, derived from the base shape object.
- Model is painting, not a canvas
- Simple compositing modes (OVER, and maybe SATURATE for
joining glyphs)
Could meet most needs pretty darn well. That is, something a lot like
Java2D, but maybe a bit simpler in some areas.
This primitive set, done with libart, would already have OK
performance for a lot of uses - and if you put XRENDER behind it, it
will blaze.
And its good enough for 98% of all printing applications. With a
little tweaking, you could probably make that 99.95%.
Regards,
Owen
(Not a design proposal, just a quick sketch of some of my thoughts
in this area.)
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]