On Wed, 28 Apr 2004 04:23:14 -0400 Jose O Gonzalez <[EMAIL PROTECTED]> babbled:
> I had an even "easier" method in mind -- use straightforward
> mathematics with real-numbers and analytic methods..
> Unfortunately, my machine seems to go into an un-documented
> "slow-motion" mode whenever it sees the words 'float' or 'double' in
> code...
> Yeah, maybe in 20 years or so...
yeah. without special hardware to do it, fp graphics is just not feasible for
realtime. :(
> At the lowest level, this can be made fairly efficient --
> For each pair of evas objects A and B, write a function for drawing
> A clipped by B (onto a dst image), as efficient as possible.
> Since 'A clipped by B' equals 'B clipped by A', one'd
> need n(n + 1)/2 functions, where n = num-of-evas-objects.
aaah but what about:
A clip B clip C clip D
A is image
B is rect
C is rect
D is polygon
we can actually do this clip with NO intermediate buffers, but what you have
requires an intermediate buffer in each stage. we need to intelligently punch
through clips until you NEED a buffer. the problem here becomes - clip buffer
management. when a clip buffer is simple (a n image, not scaled etc.) there is
no point to make a buffer - simply use the the original. but now lets say you
want to clip by a SCALED image - but the same scaled image is used to clip
multiple objects - u dont want to go rescale it every time
so u need to intelligently manage this as a clip buffer
i think u can do it by generating a clipped "scanline" then recursively applyign
the clip transforms
but you first need to generate a minimal scanline... :) anyway - doing this fast
and efficiently and intelligently isnt a walk in the park :)
> Now, if you want multiple clipping: A clipped by B,
> clipped by C, ... -- then it may depend on just how this 'exists' in
> the lib.. ie. how many objects can be 'set' as a clipping object
> at a time, etc.. Ultimately, it seems you're going to need image
> buffers of some type if you want complex lists/iterations of this
> sort of thing..
it's unlimited. u can clip by as many objects as u want :) and yes - i will
ultimately need a buffer of some sort... its managing these pre-calculated clip
mask buffers that is where the pain lies - if you use an image scaled to
2000x2000 as a clip mask for 3 icosn each 32x32 - why do we need to render the
entire clip buffer - we only need to render some PARTs of it - in fact we don't
need to malloc all of it. we only need the individual areas. this leads me to
the idea of dynamically generating (and caching) clip buffers based on tiles.
then again this tiling mechanism needs to find its way into a lot of evas's
internals at this point. :)
> But, overall, it should be straightforward to have this
> capability -- efficiently -- for 'single clipping' at least.
but the api allow multiple. so far it allows multiple rects no problems. need to
do more than rects though :)
> > well bump-map would probably be another possible filter... :)
> > combine multiple
> > filters... :)
> >
> Go for it!
iu see filters and other clip objects maybe coming into an evas2.0 much later.
we can survive without them for now. :) evas isn't a "done and finished" thing.
it can be extended over time to do a lot more. but for now i am keeping it
relatively simple :)
i'd love to see these features eventually:
* "thick" options for line objects
* polyline objects
* filled spline objects
* circle/oval/ark objects
* outline options for rect, poly, spline and circle objects
* video objects (can load .mpg, .avi files, spool files or streams themselves)
* gradient object enhancements to be able to do more advanced gradients (not
just angle, but endpoints, radial gradients etc.)
* anti-alias options for all vector objects
* right-to-left text handling for text objects
* paragraph objects (can handle full paragraph formatting for all languages
(left-to-right, top-to-bottom languages like hebrew, arabic, chinese, japanese
etc.) so u can do multiple lines, wrapping etc. all properly for the language
* fontset handling
* greymap pre-rasterised font support (to avoid massive .ttf files for large
charset languages)
* filter objects
* blur filter
* sharpen filter
* bump map filter
* color map filter (map arbitrary rgb values to a gradient of other values)
* clipping of any object to any object
* recursive evas objects (canvas within a canvas object - so u can nest
canvases)
* multiple pixel formats supported by image objects (YUV420, YUV444, RGB332,
RGB565, RGB444, RGB8 indexed etc.)
* xrender engine
* abstracted pixel-sources for image objects (eg - you can set an image object
to follow a particular X pixmap, or some other abstract source as its data
source. this would allow us, if we had an xrender engine, to use an xrender
primitive directly and build a composting manager using evas directly - with the
caveats that its the xrender engine - which doesn't exist as of right now).
* much better keyboard handling api (input methods)
* modular loader system (shared with imlib2 - merge the 2 loader api's)
* optimisations (yes there are ways of speeding evas up)
consider the above a "todo" list for evas for now. the above could keep me
(personally) busy as a fulltime job for several years. so there is a LOT to do.
:)
--
------------- 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: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g.
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
