Re: Proposal an attribute for Canvas element

If I understand correctly, the idea is that the browser could decide
whether a canvas should be rendered on the GPU or the CPU based on what
type of draw operations are performed, in order to achieve optimal
performance.

The problem with this proposal is that it assumes that anything other than
drawimage is better to be rendered on the CPU. That is an
implementation-specific and hardware-specific assumption. IMHO, we should
not be designing web stardards around the performance characteristics of a
specific implementation/configuration.  For example, text rendering on the
GPU can be made fast by caching glyphs in GPU textures (which is the case
in Chrome).

Sunyang, as you continue to improve your GPU-acceleration code you will
find that most draw operations can be made faster on the GPU.  With skia
(graphics lib use by Chrome), the main things that are still
problematically slow on the GPU are :
1) anti-aliased rendering of concave paths
2) special cases of text rendering that do not work well with glyph
caching,
3) and of course readbacks (getImageData and friends)

An alternative that would be more implementation/hardware neutral would be
to declare at creation time a list of API methods that are used, default =
everything.  But even that seems like a bad idea to me because many apps
that do not declare their canvas API requirements (legacy content) would
end up being downgraded to the non-GPU codepath, and would run slower in
most cases.

I think what Charles Pritchard suggests is a more sensible solution.  It is
not clear though whether you would want to start on the GPU or the CPU by
default.  Starting on the GPU makes sense, but you pay the price of a
readback when you make the switch over to CPU rendering.  An alternative
would be to start on the CPU, then you can decide after rendering the first
frame whether the canvas should be switched over to the GPU, based on what
types of draw calls were invoked to render the first frame. That switch
just costs you a texture upload, which is typically much cheaper than a
readback. However there is no guarantee that subsequent frames won't have
content that is slow to draw on the GPU, it's just a best guess.

   -Justin


On Thu, Nov 14, 2013 at 10:36 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> Can you describe what optimizations you are doing? Are you removing
> functionality/security checking, etc?
>
>
> On Thu, Nov 14, 2013 at 5:27 PM, Sunyang (Eric) <eric.sun@huawei.com>wrote:
>
>>  bug # is 23773,23774
>>
>>
>>
>> Example:
>>
>>    <canvas id="myCanvas" imagecanvas="true”></canvas>
>>     if imagecanvas is true, canvas only render image, otherwise operate
>> like normal case.
>>
>> Reason:
>>
>>    During development of browser, we find that,if the browser engine can
>> know that this canvas is only for drawring image and identify this
>> scenario, then the browser engine can give GPU accelaration for this
>> only-drawing-image scenario.
>>
>>    If we draw canvas, when drawimage,and there are other non-image
>> drawing,like text or line, the performance is downgraded.
>>
>>    After we implement this attribute for canvas element in our android
>> webkit kernal,we got test data for using this attribute, and not using this
>> attribute.Below is the performance comparision.We use 5 games to test our
>> implementation, and find the effect is obvious,please find detailed data
>> below.
>>
>>
>> Benefit:
>>
>>    1) for developer, this attribute is easy to use,we can draw different
>> type draw in different canvas,we can get high performance web page.
>>    2) for browser engine, it can fully optimize the performance of
>> drawing an image,make best use of powser of GPU accelerator.
>>
>>
>> Test Data:
>>
>> 1、 FishIE Scenario（
>> http://ie.microsoft.com/testdrive/Performance/FishIETank/Default.html）
>> number of fish         1 10 20 50 100
>> before（fps）           46 26 15 12 8
>> after（fps）            60 58 58 58 50
>> effect(%）     30.43 123.07 286.66 383.33 525.00
>> 2、 GUIMark3（
>> http://www.craftymind.com/factory/guimark3/bitmap/GM3_JS_Bitmap.html）
>>
>> before fps） 32
>> after （fps） 60
>> effect（%） 87.50
>> 3、 FishBowl Scenario（
>> http://ie.microsoft.com/testdrive/Performance/FishBowl/）
>> number of fish          5 10 50
>> before(fps）         5 4 2
>> after( fps）         60 60 53
>> effect（%）     1100.00 1400.00 2500.00
>> 4 CanvasGameTest
>>         fps
>> before         42
>> after         121
>> effect（%） 188.50
>>
>> 5 fishjoy
>>
>>   fps
>> before   30fps
>> after   50fps
>> effect（%）66.67
>>
>
>