HTMLTexture Bug with ZoomLevel

vvvv beta bug
#1

Hi evvvverybody, hi elias

it seems that the HTMLTexture has a bug:

When swithcing between two websites and switching their zoom levels at the same time the zoom level does not get applied correctly.

Example:
I wanna load www.vvvv.org with zoom level = 1, and then
i wanna load wwww.google.de with zoom level = 3

Reason:
It seems as if the DOM if the new website first has to be created and the zoom level can only be applied afterwards.

Needs to be fixed within the DLL i think…

thanks
Johannes

#2

example patch attached

HTMLTexture-Bug-ZoomLevel.v4p (15.2 kB)

#3

https://discourse.vvvv.org/

#4

I’ve added a hack which will re-apply the zoom level once a new website is loaded so the zoom level pin doesn’t feel that buggy anymore. But you’ll still see the zoom level for the next website being applied on the page just loaded and on the next page being loaded. You can check that behaviour in latest alpha (274a13dd6f).

There is however a more promising approach to this, for which I’ll post and answer here once the new alpha build is finished.

#5

@katzenfresser Does the answer I provided here work for you (using different slices/instances for switching websites with different zoom levels)?

#6

hi Elias.

at least it applys the zoomlevel correctly at all. thanks!!

and by knowing the workaround with the slices/instances per website one can create a smooth output without flickering.

but it’s still a workaround and i’m wondering why the node can not internally ‘reset’ the zoomlevel to the value of the inputpin properly in the right moment each time the website gets new rendered…

#7

As far as I understand the internal API our node would need to create a new browser for each external request (from Url input pin) with the proper zoom level applied. But what to do then with requests coming from the browser itself (user clicking on a link) - not sure creating new browsers for each such click would be the right approach. Not creating new browsers would lead to the same behaviour as we have it now. In any case creating new browsers all the time would need a complete restructuring the way the node works so quite an undertaking for which I’m not sure if it’s worth it…