WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
78768
Refactor DragData class to use PlatformStrategies in the Mac implementation
https://bugs.webkit.org/show_bug.cgi?id=78768
Summary
Refactor DragData class to use PlatformStrategies in the Mac implementation
Enrica Casucci
Reported
2012-02-15 18:03:14 PST
This bug track another step in the direction of removing access to NSPasteboard from the WebProcess. The Mac implementation of the DragData class needs to be redesigned to use a platform strategy that can provide different implementations for WebKit and WebKit2 and remove direct access to the NSPasteboard object.
Attachments
patch
(20.81 KB, patch)
2012-02-15 18:12 PST
,
Enrica Casucci
darin
: review+
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Enrica Casucci
Comment 1
2012-02-15 18:12:26 PST
Created
attachment 127289
[details]
patch
Ryosuke Niwa
Comment 2
2012-02-15 18:19:37 PST
Comment on
attachment 127289
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=127289&action=review
> Source/WebCore/platform/DragData.h:124 > - NSPasteboard *pasteboard() { return m_pasteboard.get(); } > + const String& pasteboardName() { return m_pasteboardName; }
Yay! one less dependency on NSPasteboard in WebCore. LGTM. I'll let someone from Mac port review this patch though.
Darin Adler
Comment 3
2012-02-16 11:00:36 PST
Comment on
attachment 127289
[details]
patch View in context:
https://bugs.webkit.org/attachment.cgi?id=127289&action=review
> Source/WebCore/platform/PasteboardStrategy.h:31 > +#include "Color.h"
Having a return type of Color requires only a forward declaration of the Color type, not an include. Files with call sites that actually call the function can include Color.h but the header need not.
> Source/WebCore/platform/PlatformPasteboard.h:29 > +#include "Color.h"
Ditto.
> Source/WebCore/platform/mac/DragDataMac.mm:70 > + Pasteboard pasteboard(m_pasteboardName); > + return pasteboard.canSmartReplace();
I think this would read better without a local variable: return Pasteboard(m_pasteboardName).canSmartReplace();
> Source/WebCore/platform/mac/DragDataMac.mm:77 > + return types.contains(String(NSColorPboardType));
Is the explicit String() needed? I am surprised it is. Did you try compiling without it?
> Source/WebCore/platform/mac/DragDataMac.mm:84 > + return types.contains(String(NSFilenamesPboardType));
Ditto. Lots more examples of this below.
> Source/WebCore/platform/mac/DragDataMac.mm:90 > + platformStrategies()->pasteboardStrategy()->getPathnamesForType(files, String(NSFilenamesPboardType), m_pasteboardName);
Ditto.
> Source/WebCore/platform/mac/DragDataMac.mm:114 > + Pasteboard pasteboard(m_pasteboardName); > return pasteboard.plainText(frame);
Same comment about not reading better without a local variable.
> Source/WebCore/platform/mac/DragDataMac.mm:136 > + return types.contains(String(WebArchivePboardType)) > + || types.contains(String(NSHTMLPboardType)) > + || types.contains(String(NSFilenamesPboardType)) > + || types.contains(String(NSTIFFPboardType)) > + || types.contains(String(NSPDFPboardType)) > + || types.contains(String(NSURLPboardType)) > + || types.contains(String(NSRTFDPboardType)) > + || types.contains(String(NSRTFPboardType)) > + || types.contains(String(NSStringPboardType)) > + || types.contains(String(NSColorPboardType)) > + || types.contains(String(kUTTypePNG));
This function is going to be really slow, creating and destroying lots of String objects. That might not matter, but if there is a chance it does matter we might want to allocate the String objects only once instead of making them every time.
> Source/WebCore/platform/mac/PlatformPasteboardMac.mm:86 > + return makeRGBA((int)([color redComponent] * 255.0 + 0.5), (int)([color greenComponent] * 255.0 + 0.5), > + (int)([color blueComponent] * 255.0 + 0.5), (int)([color alphaComponent] * 255.0 + 0.5));
I am really puzzled by the * 255 + 0.5 math here. Not at all new to this patch, but also does not seem to be the correct way to convert floating point RGBA colors to RGBA 8/8/8/8 colors.
> Source/WebKit2/WebProcess/WebCoreSupport/WebPlatformStrategies.cpp:181 > + PlatformPasteboard pasteboard(pasteboardName); > + return pasteboard.color();
Again, probably better without a local variable.
> Source/WebKit/mac/WebCoreSupport/WebPlatformStrategies.mm:144 > + PlatformPasteboard pasteboard(pasteboardName); > + return pasteboard.color();
Ditto.
Enrica Casucci
Comment 4
2012-02-17 10:34:09 PST
Thanks for the review. I've addressed your comments on the inclusion of "Color.h". I've avoided using a local variable for Pasteboard and PlatformPasteboard, also in other places landed as part of a previous patch.
> Is the explicit String() needed? I am surprised it is. Did you try compiling without it? >
Yes, it fails to compile without it.
> > > Source/WebCore/platform/mac/DragDataMac.mm:136 > > + return types.contains(String(WebArchivePboardType)) > > + || types.contains(String(NSHTMLPboardType)) > > + || types.contains(String(NSFilenamesPboardType)) > > + || types.contains(String(NSTIFFPboardType)) > > + || types.contains(String(NSPDFPboardType)) > > + || types.contains(String(NSURLPboardType)) > > + || types.contains(String(NSRTFDPboardType)) > > + || types.contains(String(NSRTFPboardType)) > > + || types.contains(String(NSStringPboardType)) > > + || types.contains(String(NSColorPboardType)) > > + || types.contains(String(kUTTypePNG)); > > This function is going to be really slow, creating and destroying lots of String objects. That might not matter, but if there is a chance it does matter we might want to allocate the String objects only once instead of making them every time.
I want to change all this in a separate patch. There are still several places where we need to convert from NSString to String and I want to do it once and for all.
> > > Source/WebCore/platform/mac/PlatformPasteboardMac.mm:86 > > + return makeRGBA((int)([color redComponent] * 255.0 + 0.5), (int)([color greenComponent] * 255.0 + 0.5), > > + (int)([color blueComponent] * 255.0 + 0.5), (int)([color alphaComponent] * 255.0 + 0.5)); > > I am really puzzled by the * 255 + 0.5 math here. Not at all new to this patch, but also does not seem to be the correct way to convert floating point RGBA colors to RGBA 8/8/8/8 colors.
I'm not sure about this code either, but I didn't want to change it without fully understanding.
Enrica Casucci
Comment 5
2012-02-17 11:54:46 PST
http://trac.webkit.org/changeset/108101
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug