On Sat, 3 Jan 2004 00:09:14 -0800 Neil Russell <[EMAIL PROTECTED]> babbled:
> On Sat, Jan 03, 2004 at 01:51:10PM +0900, Carsten Haitzler wrote:
> > no there isn't... but it'd be REALLY nice! :) if you want to contribute..
> > please first... lets talk on how your'e implimented it (lets not have aa
> > polygon code thaqts now 18 times slower... :)) and then go from there?.
> > definitely interested. aa lines is on my list too at some stage. i'd want
> > tomake it separate routines too - also "thick" lines as well (greater than 0
> > pixels) and then exporting the aa options for these primites to canvas
> > calls.
>
> Suits me. Actually, I reckon that this renderer could actually be a little
> faster than the one you have, but we'd have to test to be sure.
>
> There are quite a few issues that I need your thoughts on.
> (Go get some coffee.)
>
>
> User visible changes:
>
> * My renderer takes coordinates in floating point (actually fixed point
> integers with 16 bits mantissa and 16 bits fraction). The caller
> can place the end points inside a pixel, not just "at" a pixel.
> This is really useful in some cases, but would need an alternate API.
since evas (and imlib2) only deal in integer co-ords at the rnederer level - i
think we can just have the interface have integer co-ords and used fixed-point
inside.
> * Because of the fractional coordinates, you have to decide where exactly
> a coordinate falls in a pixel. The poly renderer wants it to start at
> the top left of a pixel. That is, 10.5, 10.5 is right in the middle of
> the pixel at 10,10. If this is different elsewhere, then we'd have to
> adjust coordinates before rendering.
yup.
> * There's also the issue of winding numbers. Right now, my code will
> only render polygons drawn clockwise (or is that anti-clockwise), and
> can't handle crossings. imlib2 cheats; I'll have to think about if
> I can cheat in the same way. I can fix the restriction, but you might
> want to offer the user the option of how to wind the polygon: even-odd,
> or non-zero (or other). If the imlib2 cheat works on my code, and
> non-zero is too hard, we could leave it even-odd. (Even-odd is more
> intuitive anyhow).
imlib2's code sucks. it has bugs. look at evas's code instead :) basically its
taken as a complex polygon regardless, so winding is irrelvant unless the poly
intersects itself. i personalyl find this method the most logical and intuitive.
self-intersecting polygons IMHO are just silly :)
> * My code takes MoveTo / LineTo commands with the coordinates, so you
> can take a bite of out the poly; good for drawing characters like
> A or O.
sounds liek you made a much more generic one than me :)
> Memory usage:
>
> * My code uses a heap allocator to allocate temporary structures while
> rendering. I reckon this is the way to go, and the allocator might
> be useful in other parts of imlib2. Basically what happens is that
> I allocate a chunk of memory from malloc, then the poly allocator just
> takes the top of heap address and adds the size to it. When a rendering
> stage is done, you just restore the top of heap pointer to a saved
> location, freeing all those temporary structures in one go.
that's true - mind you gnu mallocis pretty good these days, so i just use it :)
> * My renderer only generates a single span list for each scan line and
> then renders it. Imlib2 generates all the span lists, and then renders
> all of them at once. My way saves a lot of temporary memory. However...
>
> * My renderer stores more information with each vertex, and all the
> vertexes must be sorted before rendering starts. This can be done
> as the user calls the API so when the user says GO, all is ready.
> (My renderer is inspired by the one in libArt. It calls these things
> Sorted Vector Paths (SVPs)).
that's how things work inside evas - the point list is separate - then
transformed for the renderer at poly rend time - then the transformed/generated
list is thrown out as a render may involve several stages for different tiles
and thus the base coord offset changes per render.
> Drawing pixels:
>
> * My code generates a span list, same as imlib2, except a span contains
> alpha information.
sounds good - in fact all you need is 4 points. start gradient up, full value,
end full value, end gradient down.
> * At the end, the span walker either calls a function to draw a single
> pixel at x,y with a colour (RGBA) and an alpha from the poly renderer,
> or calls a function to draw a run of pixels starting at x,y and of
> a given colour (RGBA), but the poly alpha is 1.0.
cool- evas has code for this for the runs with alpha or not. just give it a RGBA
value to blend (or write) to a pixel run and you're set. again - evas code is
nicer, but polygons are just there for completeness ONLY - i never ever ver use
them in my own code thus they are sorely neglected. if you feel they are
important to you then PLEASE by all means - help. work on the code. make the
renderer better and i can help out too. in all honesty i concentrate on evas
mainly with the gfx code, but all the code can be back-ported to imlib2 with
relative ease. i could do with spline, "thick line" code, radial "gradient
fills" in a box - but right now my main "bane" of existence in evas is the lack
of arbitary clipping to any object. right now i only support rectagles clipping.
i'd like to support arbitary alpha masks for any composite - but i want to do it
REALLY efficiently - thats the catch. for now the api in theory supports it, but
the docs explicitly say it doesnt - so if you try clip using a non rect object -
the results are not determined. tho in all honesty this is more my domain.... :)
> * My code calls one of two functions through a function pointer set up
> at the start of the renderer; yours uses a switch statement. Who
> knows which is faster.
not sure. in theory yours - but its pretty much impossible to measure. again
evas poly code is better :)
> * I have a huge array of pixel drawing functions that can draw to different
> pixel formats; I select which one at the start of rendering and set
> those function pointers. Imlib2 only draws to RGBA, but has different
> blending functions (add, sub, reshade). My stuff gets tossed, and
> we stick you your code, but...
>
> * What about using some MMX to do that final drawing, rather than those
> macros you have now, at least to draw the runs? Since there is no
> FP code in the renderer, the MMX in the blender does not need to
> fight for the FP registers on the CPU. I always wondered if there
> is a cost changing back and forth between MMX and FP.
see evas. it has span rendering functions - if theres an mmx one for what you
want it will give you the mmx (or altivec etc.) version instead and use that
function pointer :) so kind-of done... just not in imlib2 :)
> Performance:
>
> * My renderer does not use any floating point internally. Everything
> is done using integer operations. The only catch is that you need
> some 64 bit operations: 32x32 -> 64, and 64/32 -> 32. The multiply
> is one instruction on the x86, but the divide is 17 insns, but oddly,
> executes just a quick as the single divide insn on my P3.
something i never paid attention to with the poly renderer... as i never use
poly's :)
> * I don't allocate a lot of span structures for the whole polygon, then
> render. This means that there is less memory usage, and hopefully
> better cache usage. This is why I reckon mine might be faster than
> what imlib2 currently has, but only testing will tell.
but compared to the cache beatings you invoke by read/modify/write cycles on
tonnes of image pixels... this is nothing! :)
> * To draw AA polys, you must blend at the end. Blending slows things
> down. The blending only takes place on the edges; pixels inside
> can be drawn with different code that does not need to blend (assuming
> the poly colour has an alpha of 1.0). (So to compare the performance
> of my code to the old code, blending must be off.)
again - evas has better code for this :)
> API:
>
> * Keep the existing API; it's a subset of the new one.
>
> * I would suggest these new API calls:
>
> imlib_polygon_vertex(ImlibPolygon poly, int cmd, int x, int y)
> imlib_polygon_vertex_fp(ImlibPolygon poly, int cmd, double x, double y)
>
> where cmd is MOVETO and LINETO.
for imlib2 - definitely. agreed if people want fp level detail. evas alreayd
does all coords in doubles (well actually its defineable in the header - but the
default co-ord space is doubles)
> AA lines, thick lines, others:
>
> * You can draw good AA lines (thick and thin) using the poly renderer.
> Yes, it would be slower, but it allows you to handle things like
> miter/round/bevel joins and butt/round/square ends, and even arrows
> if you want to get really fancy.
yup - sounds nice. again - it's on my list for evas - along with splines,
ellipses/arcs (filled and non filled)
> The API for lines like this could be to use the new poly MOVETO /
> LINETO functions to draw the line, then call a "stroke" function,
> before calling the poly renderer. The stroke function takes the
> given path and some extra details such as line width, joins, etc,
> and generates a new path around all of the edges of the line. It is
> then rendered with the new poly renderer. (This idea is straight
> from libArt.)
right now i'd have to export a lot of these ideas out - currently they are all
opaque :)
> Non-rectangular clipping:
>
> * I wonder if instead of generating span lists at the end of the renderer
> if you could generate some other structure which could be used later
> for clipping. This would give you clipping polygons, instead of just
> rectangles.
see above... clipping in evas is currently my bane. i would like to clip to:
rectangles (done)
and now...
images
text strings
polygons
gradients
lines
BUT rememebr clipping is recursive so a drawing op can be clipped by a polygon -
then clipped by and image, then clipped by a gradient, then clipped by text then
clipped by a rectangle.
ALSO remember clipping in evas is not JUST alpha - its RGBA clipping. so you
have a clip pixel value at a point (what an input pixel is to be clipped by) and
an input pixel
output (oRoGoBoA) is...
oR = iR * cR / 255
oG = iG * cG / 255
oB = iB * cB / 255
oA = iA * cA / 255
this allows you to do just clipping if cRcGcB = 255 255 255 or ALSO tinting
based on the clipping object color (if it's an image then you can get quite
fancy)
as i said - right now i only support rectangles and color multiplication in
evas. i want to support more and make the pipeline of clipping efficient. having
to render a clip mask for every draw op might be really tought - but i havent
decided how to tackle this yet - probabyl a clip mask cache per object... not
sure... havent looked into it for a while...
> Time and people:
>
> * Part of my motivation for doing this (apart from good will that is) is
> a project that I'm doing that could benefit from this, but I'm also busy
> with other things. I reckon that this would all take me one to three
> months, given my time constraints.
>
> * I'm hoping you can take care of the API and some of the testing, and
> help with the back end blending stuff. I'll take care of the middle
> bit.
sounds good. now where do you want this? imlib2 seems to be your target - mine
is evas as its much more advanced (and useful) :)
> Hows that for starters?
>
>
> Neil.
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
熊耳 - 車君 [EMAIL PROTECTED]
Tokyo, Japan (東京 日本)
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
