composite manager thoughts

[Jaymz Julian]

On Sun, Dec 28, 2003 at 07:53:12PM -0800, Jon Smirl wrote:
> This is why I've been sending some proposals around to people about drawing text
> with pixel shaders. The basic idea is to have one shader per glyph. TrueType
> glyphs would be preprocessed into curve segments and each pixel would be tested
> if it is inside or outside the segments. To use, set the shader and then draw a
> rectangle, the shader will turn the rectangle into a glyph.  The really neat
> thing about drawing text with shaders is that it automatically scales and
> distorts with no loss of resolution.  It is possible to antialias, subpixel
> render, hint at small sizes, etc in the shader program.

Which only works on cards which have pixel shaders, of course ;).  Additionally,
I also believe the context switch comments made later are correct.  That being
said, if you were able to store the fonts in the cards memory, and just pass
that as a parameter, which *think* is possible with some of the newer 
implentations of this, then it could work well.

That said, also, unless you have FSAA turned on, the antialiasing is not free
in the texture program.  And neither is FSAA free, in fact, it is very far
from free (disclaimer: matrox parhellia doens't count :-p)

(blah blah blah reply that everyone has pixel shaders blah blah: (a) i don't, 
(b) if my gameboy advance can do it in software, X on a 500mhz pc has no 
excuse.  oh, and (c) no, i'm not going to buy a new PC just because you say
so :-p).

 --- Allen Akin <akin@pobox.com> wrote:
> > If the compositing manager is intended to perform scaling or more complex
> > geometric transformations, then you might be forced to to have a fairly wide
> > interface between compositing manager and applications.  Furthermore, it might
> > become necessary to re-render in a larger number of situations.  For example,
> > scaling down a window containing text might make the text unpleasant to read
> > unless the app re-renders with appropriate hinting.  If the scale factor is
> > nonuniform (e.g. a perspective transformation or an application of a window to
> > a curved surface), even the specification of the necessary parameters is
> > challenging.  (Though not impossible; it's similar to the geometric
> > level-of-detail problem in 3D rendering, and could be attacked at the
> > vertex-programming level.)

Well, this is required only *sometimes* - for example, a "desktop scaler" which
you actually work on (the idea being, to temporarily fit a 2048x2048 desktop
onto my crappy ass display :-p) would require this, any effect where
you are changing the scaling *FAST* would not require this (genie effect, 
the animation when changing desktop scale levels in the above example, etc), 
because the size is changing too quickly for the eye to see anyhow - the 
negative visual effects of the frame rate drop would far outweight the static
image quality increments in these cases.

I can see two easy comprimises here:
(a) have a hint parameter to the scaler which says "i'm going to scale again
very soon, so don't bother re-rendering".  (Given the state of window mangers
out there, can they be trusted to do this correctly? :-p)
(b) only re-render after the image has been at the present scale for, random
number, half a second, *OR* we have a whole mess of CPU time that we're not
using (sayh, more than 50% idle time).
(c) just re-render when there is CPU available, but this is fraught with 
marooning problems if you system is constantly heavily loaded, and is a bad
idea. 

	-- jj

-- 
Jaymz Julian aka A Life in Hell / Warriors of the Wasteland / Unreal
Coder, Visionary, Fat Ass.
"Hannibal is a serial killer. He only likes to kill and eat people. 
 Very few people have `I want to be killed and eaten' on their cards, 
 so Hannibal is out of a job." - http://cards.sf.net