https://bugs.openjdk.java.net/browse/JDK-8263886

On 3/19/2021 9:17 AM, Kevin Rushforth wrote:
That's an interesting idea about looking at the HTTP response headers and checking to see whether the file has changed. If it could be done in such a way that it minimizes overhead, it might be the best of both worlds. I'll file an RFE to look into that...not sure we'll get time to do it, though, so if someone from the community wants to take it, that would help.

Regarding an "opt out" mechanism, If someone wants to propose an API to do that, we'd be happy to consider it (as with the above, it will be more likely to get done if someone volunteers to drive it to completion). The main question I can think of that would need to be answered is: what should be the granularity of the new boolean attribute? Global (probably on Platform then)? Per Scene? Per Region (which would also need to be on the Scene with Region overriding it)? Another is around what the behavior should be of setting it from "false" back to the (default) "true".

-- Kevin


On 3/19/2021 9:08 AM, Richard Bair wrote:
Hey everybody!

These all sound like really good points. I agree with Pedro that the ability to auto-reload (especially during development) is a really great thing, but I agree with the blog post and Clemens that in production this can be problematic depending on the location of the source CSS file, and in any event does introduce some performance overhead that would be nice to avoid.

Could JavaFX look at response headers when loading CSS over HTTP/S to determine whether the CSS file can be cached and then maintain a local cache for such CSS files? That would resolve one particular issue where CSS is loaded remotely. Could JavaFX use a different mechanism for watching the CSS files when loaded from disk so that it isn’t re-read every time but only when a change had been detected? I think both of those enhancements could probably be done while remaining consistent with the existing semantics. Add the Bug fix in that Kevin mentioned and I think most of the practical problems raised by the blog post would be fixed.

Cheers
Richard

On Mar 19, 2021, at 8:34 AM, Pedro Duque Vieira <pedro.duquevie...@gmail.com> wrote:

In the blog post he makes it sounds like it isn't good for anything to have that. That it is just a bug, something that wasn't well thought through and reviewed or a pointless feature. Which I totally disagree with. I think it
can be very interesting to take advantage of that.

I think the performance problem he measured was more about the buffering issue than about dynamically reloading the stylesheet whenever there's a change. But yeah, this might have a performance impact. If there is indeed
a considerable impact, perhaps we could have a flag to opt out of this
feature. That way we can have the best of both worlds and not have this
feature impact the apps performance in production.

Cheers,


A good feature during development is not necessarily a good feature during
production, especially if it (apparently) has a significant performance
impact.
But I see your point.

On 19-3-2021 15:32, Pedro Duque Vieira wrote:
Hi

I actually totally disagree with his conclusion.

In fact, I'd say, that's one of the hidden gems of JavaFX!
Check out CSSFX and this video
https://www.youtube.com/watch?v=RELKg32xEWU
to understand the advantages of this feature (ScenicView has also
integrated CSSFX to take advantage of this).

Think about the productivity boost of tweaking your UI at runtime and not having to go through the cycle: tweak UI -> compile -> run -> (No that's not it) -> close app -> tweak UI again -> compile again -> run again ->
(No
that's not it again) -> [repeat till infinity]

Also think about the potential for adding tools that build on top of this feature. Tools like firebug or features from Chrome developer tools, etc,
that they use on the web to debug / tweak UIs during runtime.

Cheers,


On 19-3-2021 14:29, Clement Levallois wrote:
Hi all,

I just came across this blog post which complains about a badly
implemented stream reader in JavaFX. The general tone is not nice, but I figured this could be useful to the developers maintaining this area:
https://quollwriter.wordpress.com/2020/02/09/oh-javafx-why-why-why/

Best regards,

Clement
PS: I landed on this blog post because I was searching for some
pointers
on a coding problem I have with JavaFX Service / Task, which might or
might
not involve inputStreams. I share it here:

https://stackoverflow.com/questions/66707119/task-succeeds-but-the-service-onsucceed-method-is-not-triggered
--
Cl?ment Levallois
Associate Professor
emlyon business school
Twitter and Skype: @seinecle
mobile: +33(0)6 59 08 33 92

Sent with [ProtonMail](https://protonmail.com) Secure Email.

--
Pedro Duque Vieira - https://www.pixelduke.com


Reply via email to