[Webkit-unassigned] [Bug 26379] Reconsider image decoding architecture/APIs

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=26379





------- Comment #41 from treat at kde.org  2009-06-15 11:17 PDT -------
I appreciate that a lot of time has been spent trying to rectify the
disagreements over the scope of these changes and that everyone involved is
earnestly looking for the correct and proper way forward, but respectfully, I
don't think the issue is simply one of the now improper name of RGBA32Buffer. 
Were that the case, RGBA32Buffer could simply be renamed to something more
appropriate.  Rather, it is the case that the image-decoders as now configured
are no longer cross-platform and regardless whether this is a layering
violation or not, I think it prudent to consider whether this is wise in the
long term.

>From a technical perspective let's list the pros and cons mentioned as we
currently stand:

Pro:
1) As Skia is currently written (to my knowledge) this is a definite
performance advantage as it removes the necessity for a copy of the buffer into
the native Skia bitmap type.
2) ... I've seen pkasting mention that the current Vector<unsigned> is
suboptimal for Cairo and WX, but I haven't seen the details of what this will
move to and whether or not there is any possibility Cairo/WX/FooPort can share
the future backend data store.  It'd be nice to have more info please.

Con:
1) We lose flexibility in the image-decoders as they now depend on
platform/graphics
2) Duplication of effort with ImageBuffer
3) Merging with mozilla versions becomes harder
4) Introducing copy+paste code which is is frowned upon. Cairo and WX (and
presumably all future ports that wish to use this) have the exact same
implementation of  ImageDecoderFoo except for the 'asNewNativeImage' method.

Given the above, I'd like to know if it'd be possible for Skia to introduce a
ctor for its SkBitmap that can take an existing buffer without copying, much as
Cairo and Qt are doing now.  What would this lose the Skia port and/or how is
it insufficient given #2 above?

RE: Kevin 

Techical arguments do not always require empirical data of the sort you are
requesting.  Patches are often turned down based on technical reasons other
than a lack of unit tests or benchmarks.

RE: Brett

Peter has made very valuable contributions to the image-decoders.  No one
disputes that.  However, _so far_ I have a hard time seeing the benefits to the
other ports in the recent changes other than the opportunity to share the code
with the Skia port.  Maybe I'm not reading something correctly...

RE: Peter

I don't think you can honestly object that the changes _have_ made the
image-decoders less _cross-platform_.  Where before the code was not
particularly dependent on any platform, now it is.  Anyways, can you elaborate
on the pro #2 above and the related question of whether it'd be sufficient to
introduce a new ctor to SkBitmap instead to operate on the underlying
RGB32Buffer without a memcpy?


-- 
Configure bugmail: https://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.