[Webkit-unassigned] [Bug 27511] Add WinCE specific platform/graphics files to WebCore

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Aug 10 10:42:34 PDT 2009


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





--- Comment #82 from Yong Li <yong.li at torchmobile.com>  2009-08-10 10:42:31 PDT ---
(In reply to comment #81)
> (In reply to comment #79)
> > > > > I don't think this basic acknowledge of WebCore should go to ChangeLog. I've
> > > > > mentioned NativeImagePtr in there, and I think people who are familiar with
> > > > > WebCore image stuff can understand it with no problem.
> > > > 
> > > > I'm about as familiar with WebKit Images as you can expect from a 
> 
> FWIW, I agree with Eric.  I've worked on the Image code as much as anyone
> (probably more) lately, and I don't understand why you're doing this.

We are not using Qt, CG, Cairo or any other graphics library. We just use
native WINCE API. HBITMAP is ugly and some GDI APIs doesn't even exist on
WINCE. Think about QPixmap, CGImageRef...

> 
> > #elif PLATFORM(WINCE)
> > class ImageDecoder;
> > typedef ImageDecoder* NativeImageSourcePtr;
> > typedef RefPtr<SharedBitmap> NativeImagePtr;
> > #endif
> 
> The RefPtr<> here really scares me.  Every other port uses a raw pointer.  I
> fought for weeks (spread over two years) with memory problems in the Skia port
> before we managed to understand and precisely duplicate the CG and Cairo models
> of memory management for this object.  (For reference, we originally did things
> much like you're doing here.)  I am not sure if the cross-platform code will be
> both correct and efficient with this kind of usage, and it will definitely be
> difficult for others to understand what you're doing.  I strongly recommend you
> use a raw pointer and allocate/free it at the same points the other ports do.
> 
> In order to avoid deep copying, your native image object can internally
> refcount.  That's how the other ports address this issue.

Every other port? What is this?

typedef CGImageRef NativeImagePtr;

Using smart pointers is definitely an advantage, for example, it can avoid
memory leaks (about 1.5 year ago, there was a bug that FrameData leaked. Now it
has been fixed. but if all platform NativeImagePtr were reference counted, it
wouldn't even be a problem, and "clear(true)" wouldn't necessary in
~FrameData()). Not mentioning that we use SharedBitmap as both decoding buffer
and rendering buffer so that no extra memory copying is requried.

Generally, I don't think it's a good idea to throw away helpful changes just
because we want to be same as other ports. It is supposed to be
platform-specific in this case. If we do everything in the same way, why do we
need ports?

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



More information about the webkit-unassigned mailing list