HTMLTexture doesn't refresh texturesize (somehow)

Hello,

we just found a strange behaviour with the HTMLTexture in beta32.1, but I guess it has been there all along, sorry for our odd requirements ;)

Please find the patch attached with a step-by-step-guide on how to reproduce the bug.

thx
-readme

HTMLTextureRefreshBug.zip (9.1 kB)

Hmpf, I don’t think this is about the node not refreshing the content, it’s more about a feedback loop of vvvv running in one thread in combination with a html render/javascript engine running in another. Things are definitely out of sync here - just turn on/off the auto size often enough and you’ll sometimes see it succeed. Funny thing is, that it always succeeds if you set the manual height to zero. But I’m not smart enough to explain you why.

@elias: seems that the texture is new generated when the document’s height is bigger than the old one. isn’t there any possibitlity to always do so when the height changes at all?

Would be nice to find a solution for that error because it’s a really important feature for us to reduce the total amount of texture data and handle special layout cases (eg vertical aligned middle on the basis of the texture’s height)!

probably this helps in order to get the problem…

ugly-hacks-n-workarounds.rar (9.5 kB)

Latest alpha contains the following commit:

The HTMLTexture (EX9.Texture) nodes are now able to automatically set the size of their texture if width or height is set to zero.

Note that websites with scrollbars might flicker a little the first few frames when the node adjusts the size automatically. The prefered way of using that feature is to disable the scrollbars by setting the overflow attribute to hidden in CSS:

<style type="text/css">
body { overflow:hidden; }
</style>

thx a lot, Elias! the re-sizing now works for all heights in every moment.

but there is still this other issue with the missing texture for one single frame (alpha+beta built)… see the attached files plz! :)

HTMLTexture_workaround_2.zip (10.4 kB)

Ok I’ve changed the order when the outputs get assigned and new content gets loaded - this addresses nil/zero on the non-texture outputs. The texture output should benefit from the fact that textures will not get destroyed anymore as long as the actual document size is unknown or the final document size equals the previous texture size. You’ll need to wait for build bc0d4314.

great, Elias. thanks a lot!!

… but when having more than a few textures HTMLTexture (EX9.String) still outputs empty textures after changing the html-content :-/

HTMLTexture_flickering.rar (9.4 kB)

Gave it another shot:

The HTMLTexture node will now hold on to previously computed output values.
Texture/DOM/Document Size will stay the same until a new page is fully loaded.

Check soon available build 98db79b0.

sorry Elias, but i still have some trouble, even two issues now.
your commit comment does not really work for me…

problem 1:
when a new texture is created for the first time, HTMLTexture (EX9.String) (still) outputs a texture with height=0 (averaged 10 frames for me). this is very unwelcome for all graphic patchers, because other graphic elements quite often depend on the texture height, which results in a fucked up graphic… is it possible to output no texture at all, until it is rendered with the final height?

problem 2:
texture size output does not refresh when smaller DOM is re-rendered (old issure?).

(problem 3:
when updating multiple textures at the same time the textures are updated in different frames… but isn’t that a weakness of the 32bit, too?)

HTMLTexture_flickering_2.rar (9.6 kB)

ad 1)
If I understand you correctly you want a different behaviour in the first frame (Texture Out = NIL) than in later frames (Texture Out = last rendered texture). Couldn’t you simply patch that using the “Is Loading” output and an OnOpen node?

ad 2)
Should be fixed in next build (295d631e). Missed that when doing the last rework.

ad 3)
Similiar to 1). Use the “Is Loading” output. I really don’t see a different solution to this unless you want the node to be blocking. The node is working asynchronously (think of it like loading textures from file in background) and it tells you with the “Is Loading” flag when outputs hold valid data.

ad 1)
yes, you got me rigth.
i can’t find a working solution for your suggested patch-around. IsLoading doen’t seem to run in sync with Texture Out rendering textures with a height of zero. don’t know exactly hat is going on under the hood there…

Yep, true, the IsLoading flag as it is might not be in sync with the whole auto-size stuff - I could change it in a way that IsLoading will stay true as long as the document size is not known yet. Would that work for you?

probably. i would give that a try… or to put the texture-output to NIL instead…

The IsLoading output of the HTMLTexture node will now stay true as long as

  • CEF reports that it is loading content (as before)
  • DOM was not retrieved yet (new)
  • Auto-size is enabled and document size wasn’t retrieved yet (new)

I hope that’ll solve your remaining issues. You’ll need to wait for build 353c751f.

that sounds great, but does not work for us:

see the attached patch, which hopefully demonstrates, that the IsLoading is already false shortly before the Auto-Size is retrieved. so there are some frames with missing texture (as it still has a height of zero).

thanks in advance :)

HTMLTexture_flickering_4.zip (14.0 kB)

Hm looks in sync to me. Let me show you a slightly different patch. Should the IsLoading output be false (= down edge) before the document height is retrieved we should clearly see the counter go up. But it stays zero in my case - like it should.

HTMLTextureContainer help.v4p (20.8 kB)

yap, this is (and was) in sync for us, too.

But rather Texture Out is not in sync with both the Texture Size and Is Loading.

The attached patch demonstrates a workaround with 3 times FrameDelay (Value), which seems to be quite the same as in our initial example patch before you started fixing the issue within the node.

Please also have a look at the attached screenshots (extracted from a video capture i recorded with as well as without the framedelay workaround).

missing-textures-screenshots.rar (97.0 kB)
HTMLTexture_flickering_5.rar (10.9 kB)

thx Elias for the new alpha built and the patching work!
in combination with Buffer (EX9.Texture) it now works fine for us.

i attached your solution.

some more thoughts:

  • Would be nice up update HTMLTexture (EX9.String) when a new stable version of CEF is released, because it will then be based on Chrome 38+ which has the very nice feature of clear and high-quality text rendering even on high DPI displays via DirectWrite.

  • The workaround with the Buffer (EX9.Texture) is useful if you have to switch all rendered HTMLTextures of a layout at the same time (which is quite a ‘normal’ scenario). Wouldn’t it then be nice to handle the patched workaround with the Buffer (EX9.Texture) internaly inside of the node itself? It then would be nice to have a toggle input pin, to let the patcher decide how the node should behave: a) output all textures which are already loaded successfully immediately 2) wait with the output of the textures until all textures are loaded successfully.

HTMLTexture.rar (10.0 kB)