info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Can loading images with data-url become sync?
228 views
Skip to first unread message
Julian Viereck
Apr 15, 2012, 10:07:33 AM4/15/12
to
Hi,
I'm working on adding the necessary pieces to the platform, such that the printing experience for PDF.JS is what the user expects (good quality output, no margin around pages, use page-size and orientation of PDF page for printing...).
The good print quality is achieved by using a new `canvas.mozPrintCallback` API, that I'm working on in [1]. The current version of the mozPrintCallback API implies, that all data required for printing is processed and loaded in a sync way.
Fontdata is loaded sync, if the url is a data-url. I'm wondering if it is possible to make image loading sync as well, if the image.src url is a data-url. Alternatively, can a new property `sync` get added to the image object, that implies loading the image to be sync?
Best regards,
Julian
PS: The image loading code in PDF.JS looks like this:
function loadJpegStream(id, imageData, objs) {
var img = new Image();
img.onload = (function loadJpegStream_onloadClosure() {
objs.resolve(id, img);
});
img.src = 'data:image/jpeg;base64,' + window.btoa(imageData);
}
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=745025
I'm working on adding the necessary pieces to the platform, such that the printing experience for PDF.JS is what the user expects (good quality output, no margin around pages, use page-size and orientation of PDF page for printing...).
The good print quality is achieved by using a new `canvas.mozPrintCallback` API, that I'm working on in [1]. The current version of the mozPrintCallback API implies, that all data required for printing is processed and loaded in a sync way.
Fontdata is loaded sync, if the url is a data-url. I'm wondering if it is possible to make image loading sync as well, if the image.src url is a data-url. Alternatively, can a new property `sync` get added to the image object, that implies loading the image to be sync?
Best regards,
Julian
PS: The image loading code in PDF.JS looks like this:
function loadJpegStream(id, imageData, objs) {
var img = new Image();
img.onload = (function loadJpegStream_onloadClosure() {
objs.resolve(id, img);
});
img.src = 'data:image/jpeg;base64,' + window.btoa(imageData);
}
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=745025
Dave Townsend
Apr 15, 2012, 1:41:40 PM4/15/12
to
On 04/15/12 07:07, Julian Viereck wrote:
> Hi,
>
> I'm working on adding the necessary pieces to the platform, such that the printing experience for PDF.JS is what the user expects (good quality output, no margin around pages, use page-size and orientation of PDF page for printing...).
>
> The good print quality is achieved by using a new `canvas.mozPrintCallback` API, that I'm working on in [1]. The current version of the mozPrintCallback API implies, that all data required for printing is processed and loaded in a sync way.
>
> Fontdata is loaded sync, if the url is a data-url. I'm wondering if it is possible to make image loading sync as well, if the image.src url is a data-url. Alternatively, can a new property `sync` get added to the image object, that implies loading the image to be sync?
Knowing nothing about the problem I'd think it'd be better to make it
> Hi,
>
> I'm working on adding the necessary pieces to the platform, such that the printing experience for PDF.JS is what the user expects (good quality output, no margin around pages, use page-size and orientation of PDF page for printing...).
>
> The good print quality is achieved by using a new `canvas.mozPrintCallback` API, that I'm working on in [1]. The current version of the mozPrintCallback API implies, that all data required for printing is processed and loaded in a sync way.
>
> Fontdata is loaded sync, if the url is a data-url. I'm wondering if it is possible to make image loading sync as well, if the image.src url is a data-url. Alternatively, can a new property `sync` get added to the image object, that implies loading the image to be sync?
possible for mozPrintCallback to support async.
Bobby Holley
Apr 15, 2012, 1:51:41 PM4/15/12
to Dave Townsend, dev-pl...@lists.mozilla.org
>
> Fontdata is loaded sync, if the url is a data-url. I'm wondering if it is
> possible to make image loading sync as well, if the image.src url is a
> data-url. Alternatively, can a new property `sync` get added to the image
> object, that implies loading the image to be sync?
>
Not easily. We recently did a lot of architecture work to be absolutely
> Fontdata is loaded sync, if the url is a data-url. I'm wondering if it is
> possible to make image loading sync as well, if the image.src url is a
> data-url. Alternatively, can a new property `sync` get added to the image
> object, that implies loading the image to be sync?
>
sure that image notifications are _alway_ fired async (bug 572520). This
was partly for performance, and partly to simplify the code and eliminate a
whole class of tricky reentrancy bugs.
On Sun, Apr 15, 2012 at 10:41 AM, Dave Townsend <dtow...@mozilla.com>wrote:
> Knowing nothing about the problem I'd think it'd be better to make it
> possible for mozPrintCallback to support async.
Cheers,
bholley
Julian Viereck
Apr 15, 2012, 4:13:47 PM4/15/12
to dev-pl...@lists.mozilla.org
Thanks for the fast replies!
> Not easily. We recently did a lot of architecture work to be absolutely
> sure that image notifications are _alway_ fired async (bug 572520).
Are "image notifications"=sending the onLoad event to all listeners? It would be fine if that happens in an extra event loop, but the image would be required to be loaded right after setting the image.src internally, such that the image can be used to draw to a canvas within the same event loop.
> > Knowing nothing about the problem I'd think it'd be better to make it
> > possible for mozPrintCallback to support async.
Making the mozPrintCallback API async is not trivial. Therefore I want to check that the problem can't be solved by making image loading sync - whether that's possible at all or how complicated it is to implement.
Cheers,
Julian
> Not easily. We recently did a lot of architecture work to be absolutely
> sure that image notifications are _alway_ fired async (bug 572520).
> > Knowing nothing about the problem I'd think it'd be better to make it
> > possible for mozPrintCallback to support async.
Cheers,
Julian
Boris Zbarsky
Apr 15, 2012, 4:20:49 PM4/15/12
to
On 4/15/12 4:13 PM, Julian Viereck wrote:
> It would be fine if that happens in an extra event loop, but the image would be required to be loaded right after setting the image.src internally, such that the image can be used to draw to a canvas within the same event loop.
That would violate the HTML5 spec, last I checked. So if you want this,
> It would be fine if that happens in an extra event loop, but the image would be required to be loaded right after setting the image.src internally, such that the image can be used to draw to a canvas within the same event loop.
you'd need to get it changed in the spec...
-Boris
Julian Viereck
Apr 15, 2012, 4:03:28 PM4/15/12
to dev-pl...@lists.mozilla.org
Thanks for the fast reply!
On Sunday, April 15, 2012 7:51:41 PM UTC+2, Bobby Holley wrote:
> >
> > Fontdata is loaded sync, if the url is a data-url. I'm wondering if it is
> > possible to make image loading sync as well, if the image.src url is a
> > data-url. Alternatively, can a new property `sync` get added to the image
> > object, that implies loading the image to be sync?
> >
>
> Not easily. We recently did a lot of architecture work to be absolutely
> sure that image notifications are _alway_ fired async (bug 572520).\\\
If the "notification" is the "call the onLoad" event, that's no problem if it happens async. The image needs only to be ready, such that it can get drawn to a HTML Canvas directly after the image.src was specified.
> > Knowing nothing about the problem I'd think it'd be better to make it
> > possible for mozPrintCallback to support async.
Making the mozPrintCallback async is not trivial. Therefore I want to make sure we can't solve the problem by making image loading sync (or: figure out how much work it is to make it sync, if possible at all).
Cheers,
Julian
On Sunday, April 15, 2012 7:51:41 PM UTC+2, Bobby Holley wrote:
> >
> > Fontdata is loaded sync, if the url is a data-url. I'm wondering if it is
> > possible to make image loading sync as well, if the image.src url is a
> > data-url. Alternatively, can a new property `sync` get added to the image
> > object, that implies loading the image to be sync?
> >
>
> Not easily. We recently did a lot of architecture work to be absolutely
If the "notification" is the "call the onLoad" event, that's no problem if it happens async. The image needs only to be ready, such that it can get drawn to a HTML Canvas directly after the image.src was specified.
> > Knowing nothing about the problem I'd think it'd be better to make it
> > possible for mozPrintCallback to support async.
Cheers,
Julian
Bobby Holley
Apr 15, 2012, 6:58:16 PM4/15/12
to Julian Viereck, dev-pl...@lists.mozilla.org
On Sun, Apr 15, 2012 at 1:13 PM, Julian Viereck <
julian....@googlemail.com> wrote:
> Thanks for the fast replies!
>
julian....@googlemail.com> wrote:
> Thanks for the fast replies!
>
> > Not easily. We recently did a lot of architecture work to be absolutely
> > sure that image notifications are _alway_ fired async (bug 572520).
>
> Are "image notifications"=sending the onLoad event to all listeners? It
> > sure that image notifications are _alway_ fired async (bug 572520).
>
> would be fine if that happens in an extra event loop, but the image would
> be required to be loaded right after setting the image.src internally, such
> that the image can be used to draw to a canvas within the same event loop.
>
Image notifications are the way that code like the DOM finds out about the
> be required to be loaded right after setting the image.src internally, such
> that the image can be used to draw to a canvas within the same event loop.
>
load progress of images. It's possible we could jigger up something special
and non-standard in nsImageLoadingContent, but I don't really think we want
to go down that road.
Henri Sivonen
Apr 16, 2012, 10:16:47 AM4/16/12
to dev-pl...@lists.mozilla.org
On Sun, Apr 15, 2012 at 5:07 PM, Julian Viereck <jvie...@mozilla.com> wrote:
> The good print quality is achieved by using a new `canvas.mozPrintCallback` API, that I'm working on in [1]. The current version of the mozPrintCallback API implies, that all data required for printing is processed and loaded in a sync way.
That seems like a very bad a API design assumption.
> The good print quality is achieved by using a new `canvas.mozPrintCallback` API, that I'm working on in [1]. The current version of the mozPrintCallback API implies, that all data required for printing is processed and loaded in a sync way.
> Fontdata is loaded sync, if the url is a data-url.
scheme like that.
> I'm wondering if it is possible to make image loading sync as well, if the image.src url is a data-url. Alternatively, can a new property `sync` get added to the image object, that implies loading the image to be sync?
main thread and SVG documents can appear as images. Doing parsing off
the main thread implies that to get anything done from the point of
view of the main thread, there are at least two main-thread event
queue tasks involved: one task that sends data to the parser thread
and another task that handles getting data back. Even for bitmaps, I
think it is a bad idea to lock us into assumptions about to decoding a
large bitmaps as a single main-thread event queue tasks.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Julian Viereck
Apr 15, 2012, 4:03:28 PM4/15/12
to mozilla.de...@googlegroups.com, dev-pl...@lists.mozilla.org
Thanks for the fast reply!
On Sunday, April 15, 2012 7:51:41 PM UTC+2, Bobby Holley wrote:
> >
On Sunday, April 15, 2012 7:51:41 PM UTC+2, Bobby Holley wrote:
> >
> > Fontdata is loaded sync, if the url is a data-url. I'm wondering if it is
> > possible to make image loading sync as well, if the image.src url is a
> > data-url. Alternatively, can a new property `sync` get added to the image
> > object, that implies loading the image to be sync?
> >
>
> Not easily. We recently did a lot of architecture work to be absolutely
> > possible to make image loading sync as well, if the image.src url is a
> > data-url. Alternatively, can a new property `sync` get added to the image
> > object, that implies loading the image to be sync?
> >
>
> Not easily. We recently did a lot of architecture work to be absolutely
> sure that image notifications are _alway_ fired async (bug 572520).\\\
If the "notification" is the "call the onLoad" event, that's no problem if it happens async. The image needs only to be ready, such that it can get drawn to a HTML Canvas directly after the image.src was specified.
If the "notification" is the "call the onLoad" event, that's no problem if it happens async. The image needs only to be ready, such that it can get drawn to a HTML Canvas directly after the image.src was specified.
> > Knowing nothing about the problem I'd think it'd be better to make it
> > possible for mozPrintCallback to support async.
> > possible for mozPrintCallback to support async.
0 new messages