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 :)
> > .....
> > > 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 :)
> > 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 :)
> > bingo. this
> > hasn't been done yet due to simplicity and optimization reasons.
> > long before
> > that it wasn't done due to opengl not fully supporting pbuffers for
> > a long time.
> > 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... :)
--
------------- 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
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
enlightenment-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
