Terra Informatica Forums » htmlayout

Is there a performance guideline ?

(18 posts)

  1. jeffchen
    Member

    Hi,

    We know HTMLayout can deal with some complex css and html code. Is there a performance guideline that tells us what kind of code/css/html that will cause performance issues? So we can fine tuning our code to make HTMLayout get the best performance.
    I think that will benefit the whole community.

    Thanks

    Posted 6 years ago #
  2. andrew
    Key Master

    Difficult, but I'll try to start here and move it to somewhere in the wiki.

    There are two major tasks that consume most of resources:

    1) Measuring - computation of layout of all elements. Measuring happen on WM_SIZE and while handling update(), set_state(,,TRUE) and set_value().

    2) Drawing, it can be consuming when drawing deep hierarchies with transparent/semi-transparent backgrounds.

    In principle these tasks are consuming in all browsers too. Browser may or may not use optimizations I am using internally.

    So about measuring and dynamic updates...

    Consider following markup ( [] used instead of <> ):

    [p]... [span id=\"dynamic\"]Some text to update[/span] ... [/p]

    When you update() that span#dynamic engine must recalculate layout of [p]. Changed [p] may trigger recalculation of its container, etc. until first container with overflow:hidden | scroll | auto. Usually dimensions of element with overflow are independent from its content so this heuristic works in most cases.

    Consequence #1: enclose dynamic areas inside overflow:hidden|scroll|auto containers if it is possible.

    Consequence #2: styling of dynamic effects like :hover should not change dimensions of the element. Example: use following if you need to have borders in :hover state:

      div { border:1px solid transparent; }
      div { border:1px solid red; }

    Consequence #3: if you change attributes that do not require change of dimensions use element.update(MEASURE_INPLACE) - some changes in dimensions are hard to predict so this will skip checks for dimensions.

    Please remember:

    use update() as a final step of multiple changes.
    set_value() does update internally so after it update is not required.
    set_state(,,TRUE) does update() internally too.

    About drawing --------------------------------------

    Try to minimize number of layers with alpha (background png, opacity:0.xx). I think reason is clear.

    Scrolling: fastest scrolling is on overflow:auto|scroll elements with solid background (e.g. background-color: clr ). In this case for scrolling of such areas I can use ScrollDC that appears to use hardware acceleration.

    While handling WM_PAINT of fragments engine is trying to find nearest container with non-transparent background that contains area in full. And draws only that element and its descendants. So: frequently updated areas should be enclosed in non transparent background if it is possible. That rule is not so critical in most of cases. Only when you have deep hierarchies of objects and transparency and so on.

    I believe that common sense rules most of the time.

    Some other things -------------------

    Parsing is fast in principle. set_html may be even faster than manual dom insert()/update(). It does some things transactionally.

    [TBD]

    Posted 6 years ago #
  3. Ulrich
    Member

    Andrew,

    I have to assist older machines too (say Pentium 4 with 500 MHz and above).

    On those rendering of some of my (small) pages is slow (and resizing/scrolling too). They use a svg-sidebar, sometimes an image (jpg), a png as background for drop shadow simulation, some popups.

    If you would mind, have a look at an example (zip-archive) from:

    http://www.prosource.de/Temp/TestHtml.zip

    Posted 6 years ago #
  4. andrew
    Key Master

    I definitely need to do optimizations for such cases...
    For now simply remove alpha from _Shadow.png (so to convert it to 24bpp image) and it will work faster.

    Posted 6 years ago #
  5. Ulrich
    Member

    With png with solid background (no alpha) still slow. And I would prefer to stay with a transparent png because then I can allow the user to change the colors of the foreground html element.

    Sole purpose of background png is to provide a drop shadow. May be if CSS would assist drop shadows (as border-property) this could be faster (as one could get rid of using pngs).

    Posted 6 years ago #
  6. andrew
    Key Master

    "still slow".

    In latest version? And what exactly is slow? Scrolling, resizing or rendering?

    Posted 6 years ago #
  7. Ulrich
    Member

    Still slow using latest version when rendering, scrolling and resizing.

    I changed the drop shadow png to not use alpha channel and changed CSS and Html to overlay the background image of the parent div with a child div, so background color in total can be set using CSS for the child div.

    But then still drop shadow is bound to a fixed color which can not be changed by CSS.

    Posted 6 years ago #
  8. andrew
    Key Master

    "I changed the drop shadow png to not use alpha channel "

    But is it faster then? That is the question.

    I am trying to narrow down the problem.

    SVG is also not the fastest thing, btw. Probably it makes sense to check form behavior without it.

    Posted 6 years ago #
  9. Ulrich
    Member

    The png has solid colors only (no alpha) and rendering, sizing and scrolling still is slow (not faster than with a png with alpha).

    Also I had already tried a version without SVG. Does not make great difference.

    Perhaps the size of the png matters. The main area of the png is a 50x50 px rect + drop shadow on two sides. CSS is set such that the 50x50 rect is expanded. So HtmLayout has to tile for a div of say 600x800 pixels with 12x16 of the rects. I will test wether a bigger png performs better. However then will this work with a div area smaller than the png rect?

    Posted 6 years ago #
  10. andrew
    Key Master

    "However then will this work with a div area smaller than the png rect?"
    yes, it will work.

    Do you have any child windows (HWND) inside?

    Posted 6 years ago #
  11. Ulrich
    Member

    "However then will this work with a div area smaller than the png rect?"
    yes, it will work.

    So strategy perhaps should be to use a big png.

    "Do you have any child windows (HWND) inside?"

    No child windows inside.

    Posted 6 years ago #
  12. andrew
    Key Master

    "No child windows inside." ... and still slow...

    Could you try to load the same document on that machine but in browse.exe?
    Will it work faster?

    Posted 6 years ago #
  13. Ulrich
    Member

    Ok. HtmLayout V.14 (newest one), old Ax wrapper from George. Testdocument unchanged, shadow pics guaranteed without alpha channel. No child windows. Hover effects for divs (changing backcolor) and for some table cells (border).

    Execution on 850 MHz Intel Pentium IV under Win2K SP6, 512 MB Ram.

    It is now even slower than it had been with previous version of HtmLayout. Rendering, scrolling and sizing is very, very slow! This is also true when running in current browse.exe with current dll.

    Also it is slow wether additional a foreground picture is included or not. With or without SVG does make no visible difference. What have you done?

    On Pentium Core 2 Duo @1.86 GHz, 2 GB Ram, Win XP SP2 it runs reasonible fast, but still some issues especially when resizing. Then one can see that rendering can not catch up with the resizing.

    If interested, html source is on:

    http://www.prosource.de/Temp/TestHtml.zip

    Posted 6 years ago #
  14. andrew
    Key Master

    http://www.prosource.de/Temp/TestHtml.zip

    Error 404 - Not found

    Posted 6 years ago #
  15. Ulrich
    Member

    Ooops. Sorry. Fixed.

    Posted 6 years ago #
  16. andrew
    Key Master

    I've tested your file in browse.exe on Pentium III-M running on 399 MHz/batteries.
    I see no problems with your sample. Yes, it is slower than on desktop but responsive enough.

    Yes, scrolling could be faster but this is how you have designed your page.

    By declaring:

    body {background-image:@SIDEBAR;
          background-attachment:fixed;

    you effectively instruct the engine to do not use hardware scrolling. I think reason should be clear.

    One more thing.

    svg image as a background is a cool idea of course...

    To be able to render that SVG image reasonably fast I am creating bitmap buffer for it.
    Size of the buffer is a size of destination area of the image. In case of fixed image that is the whole view. And that bitmap has alpha channel as SVG can be transparent. And it is in your case. So effectively you have four layers of background drawing of single pixel on the screen. And two of them with alpha channel. And you plan to use such forms on old machines that probably just have generic driver installed. So no hardware acceleration for even BitBlt.

    That is exactly what I meant when I said that common sense rules.

    I am not a magician, sorry.
    Well, at lest my level does not allow me to transform water into the wine and the like.

    And yet, things like:

    <body>
    
      <table.container>
        <td>
          <include src=\"Support/_TopInclude.html\" />
          <include src=\"Support/_MainInclude.html\" />
        </td>
      </table>
    
    </body>

    can safely be replaced by just

    <body>
       <include src=\"Support/_TopInclude.html\" />
       <include src=\"Support/_MainInclude.html\" />
    </body>
    Posted 6 years ago #
  17. Ulrich
    Member

    I hope you are kidding regarding the table. This should not influence rendering that much (indeed I even tested it!). In the case you mentioned: yes, here it is not necessary to use a table. But there are other cases (picture on the right side) and then a table is helpful.

    Ok, I identified three cases:

    Case A:

    body {/*background-image:url(_Sidebar.svg);
          background-attachment:fixed;*/
          ...

    This is fasted (although it could be snappier on the old machine).

    Case B:

    body {/*background-image:url(_Sidebar.svg);*/
          background-attachment:fixed;
          ...

    This is slower.

    Case C:

    body {background-image:url(_Sidebar.svg);
          background-attachment:fixed;
          ...

    This slowest and really ugly on slow machines.

    For the tests I have removed the transparent rect in the svg (which is not necessary). The svg boils down to:

    <?xml version=\"1.0\" standalone=\"no\"?>
    <svg viewBox=\"0 0 70 1000\" preserveAspectRatio=\"none\"
         width=\"60\"
         xmlns=\"http://www.w3.org/2000/svg\" version=\"1.1\">
      <g font-family=\"Verdana\" font-weight=\"bold\" font-size=\"60\"
         fill=\"blue\"
         stroke=\"bisque\" stroke-width=\"3px\"
         transform=\"rotate(-90 0 0) translate(-500,55)\">
        <text text-anchor=\"middle\" x=\"0\" y=\"0\">Sidebartext here</text>
      </g>
    </svg>

    But, as HtmLayout can not render text in svg, I have to use the text converted to a path:

      <g fill=\"blue\"
         stroke=\"bisque\" stroke-width=\"3px\"
         transform=\"matrix(0,-1,1,0,55,500)\">
        <path
          d=\"M -420.14648,-21.767578 C -420.14653,-17.70506 -421.07426,-14.067369
    ... some 29 kB in between
    466.02539,-32.900391 z \" />
      </g>

    I noticed that repainting is always slow (in Case B) and slower (in Case C). It does not matter wether the part of the view, that had been hidden and now needs to be redrawn includes the sidebar area or not. Something I do not understand because when in Case C the sidebar with the svg was not hidden by another window, it does not needed to be redrawn. So redrawing should work faster when the sidebar was not hidden.

    Also in case B, where there is no svg I do not understand why redrawing is slower than in Case A.

    Then, as the difference in speed between case B and C must be due to the time it costs to render the svg, there being able to render text and not to have to resort to render pathes shouild help.

    Posted 6 years ago #
  18. andrew
    Key Master

    table is indeed nothing compared with other things.

    About SVG basics. Attribute viewBox on svg element establishes scaling and origin of coordinate system.
    Please read: http://www.w3.org/TR/SVG11/coords.html#ViewBoxAttribute .
    As you may see viewBox uses unit-less values - they are not pixels.

    Actual size of canvas is determined differently.

    For [img src="****.svg" width=300 width=200 /] engine will create canvas (buffer) of size 300/200 px.

    As I said above, canvas space for the fixed image is the whole view. Try to think why and I am pretty sure you will get an idea.
    So I do create 32bpp buffer for the svg, render it there and use that buffer for subsequent drawings. I am not storing SVG dom - rendering is slow and expensive.

    Your layout should look like this:

    +---+--------------------+
    |   |                    |
    |   |                    |
    |svg| scrollable         |
    |   | container          |
    |   |                    |
    |   |                    |
    +---+--------------------+
    

    Where main content lives inside scrollable container.
    If that scrollable container has solid color background then I'll be able to use ScrollDC api. ScrollDC uses hardware as a rule.

    Posted 6 years ago #

RSS feed for this topic

Reply

You must log in to post.