[Webkit-unassigned] [Bug 21816] Clean up ImageBuffer.h so there do not have to be separate ifdefs for each platform
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Oct 23 08:15:33 PDT 2008
https://bugs.webkit.org/show_bug.cgi?id=21816
------- Comment #3 from brettw at chromium.org 2008-10-23 08:15 PDT -------
(In reply to comment #2)
> (From update of attachment 24580 [edit])
> - IntSize size() const { return m_size; }
> + const IntSize& size() const { return m_size; }
> What is the reason for this change, the ChangeLog doesn't say? On many systems
> it is possible to pass an IntSize in a register.
I just thought it was an error. The constructor and create() both take the
argument by reference, and this is certainly what I'm used to from other places
in the code like GraphicsContext.h. It seems like argument passing conventions
should match the return type conventions for this kind of thing. I can change
them all to by-value if you want.
> + mutable std::auto_ptr<PlatformImageBuffer> m_platform;
> This shouldn't be an auto_ptr and should instead just be a member. It could
> also use a better name. Perhaps PlatformImageBuffer m_platformImageBuffer;
>
> + ImageBuffer(std::auto_ptr<PlatformImageBuffer>, const IntSize&,
> std::auto_ptr<GraphicsContext>);
> This should not take auto_ptrs. I don't even think it needs to take a
> PlatformImageBuffer as a parameter. It should just instantiate one itself.
>
> The rest of the patch is based on the model above and thus should be changed as
> well. As such, I will only list the style issues from here on.
I did it this way because create() is supposed to return null if the bitmap
couldn't be created. This means that the subset of platform-depenedent work
that can fail must happen in create(). Given I wanted to have the same
constructor for all platforms, the only option that I can think of is to create
the platform-dependent data outside of the constructor and pass it in.
--
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.
More information about the webkit-unassigned
mailing list