I think you are right, it doesn't seem that Firefox is affected by rendering with *use* or *rect*. However, chrome seems to be more efficient when not using *use*. I update my gist to add more tiles to it to make testing performance easier. https://gist.github.com/Shump/bd778bde23af0dd3f8c95f92ec45fc33
For all version (use, no-use, firefox, chrome) *updateIfNeed* javascript function always take about the same time (~4ms on my machine). Rendering takes about 10ms *except* for chrome with no use tags, which is super fast (under 1ms). What I find weird is that if you put a breakpoint in the updateIfNeeded function, you can see the diff always calculates 200 patches (2 times the # of tiles...) and they all seem to contain event updates... On Friday, February 10, 2017 at 12:20:31 AM UTC+9, OvermindDL1 wrote: > > Hmm, I saw no difference between them in rendering times in Firefox, maybe > it is a Chrome bug with xref then? Maybe try making a pure > html/svg(/javascript) version and see if the same issue occurs? > > > On Thursday, February 9, 2017 at 4:53:07 AM UTC-7, Julian wrote: >> >> On Thursday, February 9, 2017 at 1:07:27 AM UTC+9, OvermindDL1 wrote: >>> >>> It is not strictly be design (that might be a bug if you can come up >>> with a simple descriptive example that we can copy into elm-try or so), but >>> it is easy to work-around. >>> >> >> Did you try my gist? I updated it to make it easier to work with elm-try. >> https://gist.github.com/Shump/bd778bde23af0dd3f8c95f92ec45fc33 If you >> run each of them and enable "Paint Flashing" in chrome's devtools (open >> console -> click "three dots" option menu -> click "Rendering" -> check >> "Paint Flashing"), you'll see that the version with *use* tags repaints >> the whole board (bad performance), and the one using "normal" shapes only >> repaints the hovering tile (good performance). >> >> >>> What I do is make just an integer (some primitive value), and just >>> increment it whenever the view should be updated (gotta be careful to catch >>> all cases though), then use that as the key in a `lazy` call that then >>> wraps the rest of the view, that way the view only updates when the integer >>> key is incremented (I wrap it around at 2 billion just-in-case that ever is >>> hit). >>> >>> However that makes the diff compare only the key before checking >>> everything else, and if the key integer is unchanged then the entire view >>> is skipped for diffing, thus making it very fast. :-) >>> >>> You can add more keys and more lazy's for sections of the board as well >>> if you need to get more fine grained. Just always try to use a primitive >>> as the key or a record that is passed verbatim from model update to model >>> update. >>> >> >> I feel like it shouldn't be necessary to look into adding keys for >> performant rendering with *use* tags when it is not needed for "normal" >> shapes... This is why I'm wondering if this might be a bug... or if it >> turns out that this is intentional, and *use* tags are performance >> killers, it should probably be mentioned in the documentation... >> >> I'm sorry if this wasn't clear in my original post... I hope this makes >> things clearer. >> > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
