What would it take to allow the visual contents of a Custom HTML panel to appear as a clip in a timeline?

[Premiopolis]

Or any HTML content. Would love the ability to create an HTML file, format it 3840x2160 or 1920x1080, etc, give the body background-color an opacity of 0, and and run full HTML/CSS/JS directly in a timeline.  It's a little out there, but would be a great extra way of getting lower 3rds and any other info quickly, easily, dynamically into an edit.

[ETorr]

sberic  wrote

I think I would probably structure things a little differently to avoid the requirement of a "pre-render" delay. I would probably have the interface be: "Here are some times. [Wait.....] Oh! Thanks for the frame!" This would assume that the contents of the browser had its own internal timeline that you would simply be syncing with the "time" value. You could also develop a setup that would freeze time until "pumped" by this request (via a time delta) - effectively, only ticking the webpage when the plugin in PP or AE requests a frame.

I would operate on the assumption of a browser without an internal timeline.  You could certainly code one up, but unlike an AE frame, a browser window never really knows when it's done loading content.  The native logic of a browser page is to gather its assets asynchronously.  The browser page is complete only after the last asset falls into place, and even then it might contain timeOuts and setIntervals that evolve the page indefinitely.

In other words I'm thinking under the assumption that a feature like this would serve a variety of uses, both locally-hosted pages wholly developed & managed by the production team, but also web-hosted pages, content from various sites over which you have no control over the content.

Once you open up Adobe AE / PPro to integrate HTML content, the possible ways of using it are quite numerous.

So going back... when a web page receives AE's "time" value via query string, it's not perceiving it as actual time, just a value that the web developer can use to dynamically render the page according to whatever logic is appropriate.

And the point of a delay-before-render is to give pages enough time to load.  Locally-hosted wholly-controlled pages could be coded up to render within a second or fraction thereof so set a pre-delay to 1sec or .5 if that'll do it.  Meanwhile  https://forums.adobe.com/inbox  takes about 5 seconds, so set the delay to 5.5 or 6 -- whatever makes the process reliable.

[sberic]

ETorr  wrote

In other words I'm thinking under the assumption that a feature like this would serve a variety of uses, both locally-hosted pages wholly developed & managed by the production team, but also web-hosted pages, content from various sites over which you have no control over the content.

I see. Something that flexible would most certainly require that kind of input.

But if you're going that far, I would suggest doing a simple screen-capture. My understanding was that HTML/JS could be useful for creating interesting UI. My followup assumption is that the default "white" background of the webpage would actually be alpha=0 so that you could create graphical overlays for various features. If you're using it to capture something live into a render, well... I could see that being useful for sure, but I'm not sure I see what gains you get out of simply importing a screencap...

Still a neat idea to explore!

[ETorr]

sberic  wrote

But if you're going that far, I would suggest doing a simple screen-capture. My understanding was that HTML/JS could be useful for creating interesting UI. My followup assumption is that the default "white" background of the webpage would actually be alpha=0 so that you could create graphical overlays for various features. If you're using it to capture something live into a render, well... I could see that being useful for sure, but I'm not sure I see what gains you get out of simply importing a screencap...

Still a neat idea to explore!

sberic  wrote

My understanding was that HTML/JS could be useful for creating interesting UI.  My followup assumption is that the default "white" background of the webpage would actually be alpha=0 so that you could create graphical overlays for various features.

There's a lot of power under the hood of HTML/CSS/JS.  It's hardly a replacement for the sophisticated rich visual environment AE offers, but when it comes to handling data to generate dynamic (albeit simpler) visuals HTML can (not always) be a faster design+code environment.

RE "white" background: Actually you can define the the "document" or "document.body", of a web page as having a background alpha from 0 to 1 in decimal increments (so effectively anything from 0% to 100% opacity).  Likewise any element in a web page can be defined, either it's backgroundColor or overall opacity the same way.

sberic

If you're using it to capture something live into a render, well... I could see that being useful for sure, but I'm not sure I see what gains you get out of simply importing a screencap...

A web page can be any size, extending beyond the screen via scrolling.

If you're developing custom overlays for HD or UHD etc, you could define your HTML doc width to match (1920x1080, 3840x2160 etc)

But 3rd party remote sites are whatever they are, extending down however long.

Theoretically the rendered web content could capture that excess page, and allow you to pan & zoom over it in the same way you can now manipulate oversized media, whereas a screen grab is only as big as the screen from which it's grabbed.

[sberic]

ETorr  wrote

There's a lot of power under the hood of HTML/CSS/JS.  It's hardly a replacement for the sophisticated rich visual environment AE offers, but when it comes to handling data to generate dynamic (albeit simpler) visuals HTML can (not always) be a faster design+code environment.

Totally agreed here. I think the only thing I'd strike from that statement would be the"albeit simpler" caveat. AE lets you do a lot of neat stuff (and quickly!), but there are some very complex things that you may want scripted control over and the web is becoming quite a platform for that kind of thing (WebGL 2.0 enables, well, just about anything you care to throw onto a GPU...).

ETorr  wrote

RE "white" background: Actually you can define the the "document" or "document.body", of a web page as having a background alpha from 0 to 1 in decimal increments (so effectively anything from 0% to 100% opacity).  Likewise any element in a web page can be defined, either it's backgroundColor or overall opacity the same way.

I was aware that you could set those values. I mentioned the "white" color because my understanding (assumption?) was that if you set a simple HTML page's background color to alpha=0 it would still show white (white being what the browser presumably uses as a "clear color").

ETorr  wrote

A web page can be any size, extending beyond the screen via scrolling.

If you're developing custom overlays for HD or UHD etc, you could define your HTML doc width to match (1920x1080, 3840x2160 etc)

But 3rd party remote sites are whatever they are, extending down however long.

Theoretically the rendered web content could capture that excess page, and allow you to pan & zoom over it in the same way you can now manipulate oversized media, whereas a screen grab is only as big as the screen from which it's grabbed.

It's not a theoretical Have you seen that Chrome 59 included a new Headless Mode feature? You can use it to easily create screenshots at whatever resolution you care to request. If you don't want to go through the "hassle" of headless mode, you could also simply open the DevTools and manually snap a screenshot!

It looks like this functionality is also available in Chromium. There may be a way to take multiple consecutive screenshots of a webpage using the setup or even extend it to a video capture. But... that's kind of what we've been talking about already anyway 😜

[ETorr]

You may have just made my day, maybe my month.  Now I'm not going to get anything else done.

[sberic]

One thing I just noticed while closing my tabs is this Puppeteer project over on GitHub. It's a NodeJS package that allows, amongst several other things, screenshot grabbing... Seems pretty darn neat!

[Premiopolis]

sberic  wrote

One thing I just noticed while closing my tabs is this Puppeteer project over on GitHub. It's a NodeJS package that allows, amongst several other things, screenshot grabbing... Seems pretty darn neat!

Thanks for this one.  Been testing it, and it's already proving to be helpful.  Not too hard to implement.  The challenge will developing a means of producing animation on a per-frame basis.  Not intrinsically easy but it seems achievable.  Thanks again.