[Webkit-unassigned] [Bug 11332] SVG support for Linux port

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=11332





------- Comment #11 from mike.emmel at gmail.com  2006-10-18 09:08 PDT -------
(In reply to comment #8)
> Heya Mike!
> 
> First of all I really like your interessest regarding a Cairo/gdk based
> SVG rendering device! Though I am not sure wheter it should go in, because:
> - Since some months, there is following plan floating around:
> 
>   KCanvas own RenderingDeviceContext should die, and the functionality
>   of it should be merged into GrahpicsContext directly. That will eliminate
>   a lot of confusion. The resources (masker, clipper, marker, patterns,
>   gradients, filters) etc. of need to be merged into platform/ code as an
>   follow-up patch.
> 
> We currently only have a Qt-device & Quartz rendering device in kcanvas/device
> in WebKit. If the KRenderingDeviceContext kill happens, we already need to
> change & test two implementations, a third one in SVN is one more to fix.
> 
> As stated above, this area is supposed to change a lot. If you want to
> commit this SVG rendering device in SVN (to save bitrod), this is no problem
> (for me) at all, though you are warned, that you'll probably need to fix
> a lot, when this change happens.
> 

Not a problem I'm committed to to this SVG is the heart and sould of the Gdk
port otherwise it won't work.

I'd suggest you take a hard look at my patches there were some serious problems
with affine transforms and the html renderer I have to have foriegnObject
working correctly. I'd suggest that before you do major work on svg you
consider making the html renderer affine transform aware. It uses m_x,m_y fixed
offeset and does not understand translation and there seemed to be a number of
bugs with
embedding the html in SVG.  Next if you allow and arbitrary transform for the
embedded object then you need to go with my lightweight frame concept which has
its own set of problems that need to be worked out since the hitdetection code 
did not work correctly FrameView's coordinates were put at 0,0.

My patch contains changes that allow all this to work correctly despite the
problems but its not the cleanest solution since I did not wan't to change
a lot of the basic render classes. My suggestion is to incorporate the
transform into the basic rending first then look at further changes for svg.

Next as far as cairo goes. I think we must work closely with the cairo team to
get a good implementation. And agian if you look at my code you will see that I
made GraphicsContext equal to a cairo context and made path a context.

The problem with cairo is that path is not a first class object and probably
never will be. This means its easy to take other drawing libraries and create a
cairo like api but its really hard to  take cairo and use it to implement a api
it was not designed for.

So if their is any intrest in a good cairo port I really think we need to
consider cairos unique global context first and make the api compatible with
that. Other systems can trivially emulate the behavior with no loss in
performance.

What this means is we have to define the destination surface at the very
begining 
before we even parse the svg. This will allow us to cache cairo_t's for the
surface and use them later during the rendering process so the performance can
be quite good. Once I accepted cairo's design I realized it was probably the
best for high speed complex 2D drawing. The rendering engine should then use
the cached cairo_t's for rendering. So if you go with cairo's design you can
get fast rendering for cairo and its easy to emulate a cairo_t in other api's.
If you don't then cairo will always be too slow. I think cairo has it right
since it allows you to optimize the 2D drawing path for the destination so you
don't have to do a lot of complex math during the rendering phase.

This means the target surface needs to be a global and if you change targets
say go to printing or offscreen we need a way to reset cairo info for the new
target.

So cairo is a catch 22 api if you follow its design you can probably get faster
2D rendering then other approaches if you try and force an alternative api on
cairo then cairo will be slow.


> For me, new semester started today, and it'll take some time until I have
> sufficient time for SVG hacking in WebKit - though this GraphicsContext
> <-> RenderingDeviceContext merge is up on my todo list). If you feel
> like working on it, this would be highly appreciated :-)
> 
> Greetings,
> Nikolas Zimmermann
> 


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.