Open Bug 1310669 Opened 8 years ago Updated 2 years ago

Canvas 'drawImage' not rendering non cached dataURL resources

Categories

(Core :: Graphics: Canvas2D, defect, P3)

defect

Tracking

()

UNCONFIRMED

People

(Reporter: kontakt, Unassigned)

Details

(Keywords: testcase, Whiteboard: [gfx-noted])

Attachments

(2 files, 1 obsolete file)

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160922113459

Steps to reproduce:

I need to render multiple small images on bigger canvas received from network in javascript event. It can be over a dozen calls in a second.
My simple implementation looks like this:
function(img, x, y) {
    var i = new Image;
    i.src = img;
    cctx.drawImage(i, x, y);
}
where cctx is 2d canvas context obtained by "canvas.getContext('2d')".


Actual results:

In Firefox (version 49.0.1) my canvas shows only little percent of all calls.
In most cases only last of multiple "simultaneously" received events was successfully rendered.


Expected results:

Canvas should render all of drawImage() calls.
Could you attach a testcase to the bug report, please.
Flags: needinfo?(public)
Keywords: testcase-wanted
Ok, I prepared very simple demo for this and while I am doing it I noticed that it can be a problem with cache.

I cannot prepare real life demo because problem happens in network application with fairly lot of dependencies but I tried to make similar example.

When you open my "index.html" first time you should see black canvas, but when you refresh the page you should see 20 times rendered Firefox logo.
Next when you refresh page with force reload (no cache) for example by Ctrl+Shift+F5 you can see black canvas again.

It is not exactly what's wrong with my application because in real life I have over a dozen different images per second but I think problem can be there.
Flags: needinfo?(public)
Attached file index.html
What's the expected result? Firefox logos on the 1st load?
Yes, it should be rendered in first load.
We can easily imagine production situation (like in my application) where images are delivered from websocket and drawImage does not renders it.
I tested with old versions of Firefox (like FF33) and drawImage() is never called on the 1st load, only after a refresh.

I tested with IE11, drawImage() is called immediately.
Yup, but it is not function calling problem,
when I moved "render" execution from "window.onload" to another function and executed it from JavaScript console manually nothing happened on first time(when cache isn't available) but when I called same function second time Firefox logos was showed.

I tested my "really problematic" application with other browsers (MS Edge, Chrome, IE is not compatible with my app) and all works great.
Summary: Canvas draw only few of multiple fast executed 'drawImage' → Canvas 'drawImage' not rendering non cached dataURL resources
OS: Unspecified → All
Hardware: Unspecified → All
:pchang, can you find someone to look into it?
Flags: needinfo?(howareyou322)
Whiteboard: [gfx-noted]
Kevin, I think this is good practice for you.
Assignee: nobody → kechen
Flags: needinfo?(howareyou322)
Priority: -- → P3
Attached file bigimg.html (obsolete) —
Attachment #8821034 - Attachment is obsolete: true
Hello Rafał,

Sorry for the late reply, I was working on other tasks.

According to w3c spec[1], if the image isn't yet fully decoded, the drawImage function will draw nothing.

I am still investigating spec for rules about decoding non-cache dataURL to figure out if it's necessary to finish the decoding immediately when it is assigned to a image.
Even there is not, maybe we can still examine our decoding process to understand the reason that other browsers can show the image in first call.

But, by the meantime, you might be able to try the solution like attachment 8821033 [details] which can ensure the image is fully decoded when drawImage is called.

Thank you.

[1] https://www.w3.org/TR/2dcontext/#dom-context-2d-drawimage
Hi, thank you for the answer.

Your fix with onload JS event works great.

But as you said we need consider what to with this.

In my investigation I found the code which drops rendering process in case of image still loading (and comment about W3C spec).
But way all other browsers waits for image load automatically (without JS hack).

Maybe it is better approach ?
and
Why we should drop that render process when the obvious intention of the user is to display image ?
I'm not actively working on this.
Assignee: kev155266 → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: