-
Notifications
You must be signed in to change notification settings - Fork 218
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Creating drag images #110
Comments
Hey, interesting use case. Indeed, there is quite a bunch of asynchrony going on internally. Quite some of it that could be worked around with a bunch of limitations though. However it looks like the core issue will be with the code actually building an image object from the underlying SVG object (see https://github.com/cburgmer/rasterizeHTML.js/blob/master/src/svg2image.js#L106). This I believe will always be asynchronous. You could double check with trying to construct an image in the code you've provided (replacing the call to rasterizeHTML).. |
There's an example on MDN. It uses an |
Interesting, so Firefox does support painting the image, even if we pass in something that hasn't loaded yet?! So I don't think hope is lost for you, however rasterizeHTML might be too heavy weight for your use case: apart from waiting for the image to be loaded, asynchrony comes in from executing JavaScript, calculating the image's canvas size, loading external references, checking for browser compatibility (blobs, workarounds for sandboxing issue), and more... Most of that, if not all, might be optional for you, but making this optional for this library will be quite a challenge. In your case you might just want to have a look at https://github.com/cburgmer/rasterizeHTML.js/blob/master/src/document2svg.js#L69, which is amongst the core functionality of the library. In your case, understanding what is happening there might be the best step forward for you to implement a lightweight version for yourself. This does not mean I intend to leave you alone with this, I'm happy to provide context along the way. However, if you are up for it, we could identify the minimum set required to generate an image from HTML in a synchronous fashion and pull it out into a small library. rasterizeHTML has gotten bigger continuously, so breaking out functional chunks would be nice. |
I understand. There is a hack out there which I'm currently using. It involves hiding the desired drag-image element behind another element on the page (it has to be in the DOM tree and positioned within the bounds of the viewport to qualify, but apparently you can still obscure it). I will keep using that hack for now, because I can't afford to spend much time on this. But just so you know, should you want to implement this in the future: There are developers out there who would see rasterizeHTML as a more elegant solution to the drag-image problem (no matter how 'hacky' the library is inside; at least it's well tested and encapsulated). |
Sounds reasonable! Let's keep the issue open as a feature request for a synchronous call. |
I'll close this issue as we can let #155 track this feature request. Feel free to re-open if you feel we've missed something. |
Hi there,
I tried using rasterizeHTML to create a drag-image for the HTML5 drag-and-drop API, but no luck so far. The drag image always appears empty:
I guess it's because rasterizeHTML works asynchronously, and the drag-and-drop API expects to receive the drag-image canvas synchronously. Setting the drag image after the
drawHTML
promise resolves doesn't work either. It then appears as if no custom drag image was set at all.Is it possible to support a 'synchronous mode' (obviously with some limitations)? Or if I'm just doing something wrong, please let me know?
The text was updated successfully, but these errors were encountered: