On Tue, 20 Apr 2004 13:36:36 +0900 Carsten Haitzler (The Rasterman)
<[EMAIL PROTECTED]> writes:
> On Tue, 13 Apr 2004 03:34:30 -0400 Jose O Gonzalez
> <[EMAIL PROTECTED]> babbled:
>
> > > technically- yes - but evas for example lacks matrix transforms,
>
> > > splines, radial
> > > fills, and several other "required" things. fonts are done
> > > differently to flash
> > > where last i checked it did them from the spline/curve/line
> > > primitives directly,
> > > and not via ttf's etc. with a LOT of effort i guess all this
> could
> > > be added and
> > > an E based SWF viewer/player would be possible - but for now i
> don't
> > > really see
> > > a need and don't have time myself. also implementing all of
> these
> > > things is no
> > > trivial task - well not trivial to make it FAST and still look
> good.
> > >
> > Indeed. It's not too difficult to write these things..
> *But*,
> > to write them accurately enough so things look good, and do this
> > FAST.. that's not so easy.
>
> oh god its DEAD simple to write them if you follow "computer science
> principles"
> you learn in school. you write a wonderfull transform pipeline,
> pixel selector
> and sampler each generic allowing you to sample an arbitrary
> polygonal area
> (generally 4 sided) from a source and gain 1 output pixel value,
> this extends to
> scaling up and down if done right. you can do scaling, rotation
> shearing,
> stretching and all - but.. here is the but - and what u don't learn
> a lot of "at
> school" - the PERFORMANCE SUCKS. you have written beautiful simple
> code thats
> maintainable - and it runs like a dog. its unusably slow. sure in 20
> years your
> cpu may be fast enuf for it to be "cool" but you want that TODAY...
> and THATS
> the problem. writing things to be fast TODAY on a cpu AND also work
> on gfx
> acceleration chips... :) doing things fast means cutting corners -
> lots of them,
> and making assumptions :)
>
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...
> > > .....
> > > > 4. Considering we have Beziers, any thoughts on SVG
> > > > rendering?
> > >
> > > we'd need bezier curve clipping (ie render image, other
> > > object/primitive clipped
> > > to a bezier curve path) in fact we really need arbitrary
> clipping -
> > > ie clip the
> > > rendered output of lets say gradients, lines, polys, images to
> any
> > > other of
> > > these in the most optimal way (or any combination of these ie an
>
> > > image scaled
> > > and blended to a dest,m but clipped to another image mask that
> is
> > > scaled
> > > differently, and this mask is clipped to a polygon that is
> clipped
> > > to a bezier
> > > that is clipped to a text glyph output.....) you get the idea -
> this
> >
> > You really only need to implement multiplication
> > of pixels to have the core for this (or at least, multiply pixels
> > by alpha pixels)... But then you'd still need a good way to
> > organize this into a workable set of interfaces..
>
> the problem here is to do this efficiently. for example if only a
> small image is
> cliped by a large one - u dont want to render the large image into a
> "clip"
> buffer mask first then only use part of it
> if that clip is shared between multiple objects u don't want to
> re-render the
> clip mask too. you also want to avoid needing a clip buffer/mask at
> all in the
> case of being clipped by rectangles or polygons where the clip shape
> and values
> are easily calculated as spans... :) now combine this efficiently...
> tough tough
> tough. the solution all windowing system use is "let the app deal
> with it" ie -
> they dont try and optimise - they simply blindly do what an app
> tells them in
> terms of using masks and buffers and the dumber the app, the slower
> it is. i
> want to do it so the app doesn't have to be smart :) that makes life
> hard :)
>
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.
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..
But, overall, it should be straightforward to have this
capability -- efficiently -- for 'single clipping' at least.
> > > is very
> > > useful. can be used for making "textured text" ie text font with
>
> > > some coloured
> > > texture in it - take an image as th texture, clip it to the font
> -
> >
> > Textured text!! Oh NOW you want textured text!
>
> well thats a bi-product of clipping :)
>
he,he,he... Well, that alone should be a good reason
to add such clipping to evas!
> > > also i want to support some filter methods. particularly
> "Blurring"
> > > of an object
> > > prior to composting. doing this fast in software is had - doing
> it
> > > fast with
> > > opengl is also hard. this would let us easily do soft drop
> shadowed
> > > text with
> > > much less overhead. it will allow all sorts of other effects
> like
> > > fading in
> > > whiles going from massively blurred to clear and sharp etc. this
> is
> > > definitely
> > > on my "some time" plan... that and clipping are right near the
> top
> > >
> > Sounds good! How about bump-mapped textured text :)
>
> well bump-map would probably be another possible filter... :)
> combine multiple
> filters... :)
>
Go for it!
-------------------------------------------------------
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
