Open dhowe opened 7 years ago
Simple Reader only
Mesostic Reader/Spawning simple Reader only
Perigram Reader only
No visual changes for the first focused word, the visual(red color and fading) starts to appear from the second word
Is this true only for the first word on a page, or for anywhere the reader starts?
Can test with:
new PerigramReader(pManager.recto, SPEED.Fluent).position(pManager.recto, 5, 5);
It is not the first word on a page, but the first word that got read (which is logged in the focused reader display)
- The color of focused word always fail to change before any page turn happens.
I assume you mean 'active' word here, yes (readers have focus, not words)?
yes, active. Updated the comment.
The slowing down of the whole browser happens even with no readers opened, so there is already some problems with the very basic of the code. After a few testing, I found that the laggy performance in firefox seems to be related with textFont in RiText._render(). If I comment out this line https://github.com/dhowe/ReadersJS/blob/master/src/rt.js#L820 and only display the grid without enabling any reader, the loading statistic I got from the console is shown below: [LOAD] Misspelt Landings 2984ms text-loader.js:64:7 [LOAD] Poetic Caption 5645ms text-loader.js:75:3 [LOAD] The Image 7116ms text-loader.js:75:3
And this is what I got if with same setting, but enabling that single line of code. [LOAD] Misspelt Landings 12788ms text-loader.js:64:7 [LOAD] Poetic Caption 19654ms text-loader.js:75:3 [LOAD] The Image 25376ms text-loader.js:75:3
According to the statistics above, there is a significant slowing down of speed with this simple change.
If I only do textFont() one time in multi-page.js setup(), it still slows down the whole page significantly, though a bit better than calling it in _render(); [LOAD] Misspelt Landings 5980ms text-loader.js:64:7 [LOAD] Poetic Caption 17811ms text-loader.js:75:3 [LOAD] The Image 21792ms
https://github.com/processing/p5.js/blob/master/src/typography/loading_displaying.js#L116
This is quite useful. You can likely get even more detailed info from the browser profilers...
Can you do a very simple test, with the same font, loaded in preload, on firefox and chrome, simply calling textFont() and then text() 1000 times in p5.js draw()? We need to isolate exactly where the slowdown is happening
Here is a test case http://chenqianxun.com/testcases/textFont/ It slows down firefox if I put both textFont() and text() in the for loop, and it still slows down firefox (a bit better than before) if I put textFont() in setup and text() in in the for loop. It consumes a lot of cpu for both chrome and firefox, but in chrome, other interaction within the browser is not affected. Should we create an issue on p5.js for this?
Can we try with a couple of different fonts first? Including the default (non-loaded) font?
http://chenqianxun.com/testcases/textFont/default.html http://chenqianxun.com/testcases/textFont/times.html http://chenqianxun.com/testcases/textFont/baskerville.html
If I don't load any font and only do text() 1000 times on canvas, it doesn't slow down the browser.
ok, and all loaded fonts are more or less the same?
lowering priority for now
Start with a single reader -- see what works, what doesn't (keep a list below). Meantime, lets add a note for Firefox users saying 'Currently only runs in Chromium browsers' and not load the page...