Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

  • mathias
    replied
    I am running the 13 beta and i'm seeing flickering. Ok, so there's some way to address it into a single file, but it should still not flicker. Thanks for the input though.

    Yeah, all SVG-related stuff works fine in Safari, breaks in Chrome+Firefox. We decided to ditch SVG completely, we don't have time to spend on crap like this :) Again thanks for help/input.

    Leave a comment:


  • Blama
    replied
    Hi mathias,

    you can use useImageForSVG and set it to true to have SVGs loaded as <img> instead of <object>. This definitely makes sense in 12.0p and older.
    12.1p and newer should be able to use nice css skinning features that will save you from the need to have multiple files for hover and click states - see here.

    In total I agree that this feature is great, but as the browser support is poor, this does not help.
    Therefore I think that <img>-tag SVGs are still the way to go. If this is an issue for you because of different CI in the same project you could apply serverside color changes to the SVGs.

    In general it would be great if you starred and commented the issue from #14 in the browser's bugtrackers to get them fixed eventually.
    Good to know that Safari is already OK.

    Best regards
    Blama

    Leave a comment:


  • mathias
    replied
    Hi, we've tried the last week to migrate to SVG for some stuff and encountered flickering right away in both Firefox and Chrome, looks pretty bad (works fine in Safari). This makes SVG unusable, doesn't it? Sounds crazy to me, do you know if they're working on it?

    Leave a comment:


  • Blama
    replied
    Anyone interested in getting the underlying browser bugs fixed, these are the issues in the respective bug trackers: Chromium, Firefox.

    Best regards
    Blama

    Leave a comment:


  • Isomorphic
    replied
    Originally posted by Blama View Post
    Hi Isomorphic,

    I don't see a difference between FF61.0.1 and Chromium 68.0.3440.106 in my application using v11.1p_2018-08-04 (is this the correct version? Or do you mean in 12.0?)
    We observed the difference in 12.1d where the "pointer-events:none" CSS issue was resolved, and across Windows, Linux, and OS X, but it should be the same in all branches as it wasn't related to that change.

    Originally posted by Blama View Post
    Just did. I assume from the date of the post #4 and the contents that this one is yours, right?
    Is there anything else I could do?
    You might want to post your actual experience in the defect comments, saying how it affects you, as that may increase the impact.

    Then, since you're still affected badly in Firefox, you might want to file a bug against Firefox as well here. If we can get one of the browsers fixed, the others will face increased pressure to also resolve this.
    Last edited by Isomorphic; 23 Aug 2018, 10:33.

    Leave a comment:


  • Blama
    replied
    Just did. I assume from the date of the post #4 and the contents that this one is yours, right?
    Is there anything else I could do?

    Best regards
    Blama

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    I don't see a difference between FF61.0.1 and Chromium 68.0.3440.106 in my application using v11.1p_2018-08-04 (is this the correct version? Or do you mean in 12.0?), but will definitely star that issue.

    Thank you & Best regards
    Blama

    Leave a comment:


  • Isomorphic
    replied
    You may have observed that the flickering for object tag SVG reloads is much reduced (though not entirely gone) in FF60ESR vs. FF52ESR, so Firefox has made progress.

    The problem is still pretty bad with Chrome so you may wish to star the associated bug here, which reports the issue as a caching problem for SVG in object tags. (If caching of SVG in object tags were improved it would likely also resolve the visible flickering.)

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    OK, thanks. I'll change that then to all-black PNG. Not a big problem for me. I have another case (non-ListGrid) though, where this is a problem. I'll try to create a testcase.

    Best regards
    Blama

    Leave a comment:


  • Isomorphic
    replied
    Upon further investigation, we really can't avoid doing the second redraw during the expansion or collapse of a group row in a grid, unless you want to disable animation (via animateFolders: false). This is because an initial redraw is done to put extra content into the row being expanded so that it can be slid into view, and thus the second redraw is needed at the end to restore the HTML to its expected record-per-table-row configuration.

    Leave a comment:


  • Isomorphic
    replied
    You can see in the Developer Console whether this is a redraw - almost certainly not. Most likely, you just have logic calling refreshRow or refreshCell, which replaces the DOM elements of the cell or row and hence would trigger the browser flicker bug.

    Leave a comment:


  • Blama
    replied
    Ok, I'll wait for this one.

    For me, there is also a redraw (if that is the root cause) for just hovering the grouping row. This seems to be related to getCellCSSText (because it only happens if I'm using this in my ListGrid), but I have not been able to reproduce in SmartClient, yet (see #1).

    Best regards
    Blama

    Leave a comment:


  • Isomorphic
    replied
    There is one extra redraw in this use case which we plan to try to eliminate. However there will still be one flicker until browser vendors fix this bug.

    Leave a comment:


  • Blama
    replied
    Hi Isomorphic,

    thanks for the hint on the docs and that this is a browser issue. I did not know this.
    Perhaps it is possible to reduce the amount calls needed to reduce flickering?

    If you replace the groupByField: "continent" by groupByField: "population" you'll notice that the amount of calls on group open/close significantly increases. As almost all icons stay the same, shouldn't there be only "one flickering image change" needed?

    Thank you & Best regards
    Blama

    Leave a comment:


  • Isomorphic
    replied
    Your screenshot cuts it off, but we're seeing these as not actual network fetches, but disk cache hits that are reported in this odd way by Chrome.

    As far as the flicker, it's not under our control - it's a browser bug - this is covered in the docs for useImageForSVG.

    Leave a comment:

Working...
X