Hello Cagatay,
I have a general question. I use a lot of PrimeFaces components in my web-app and there is always flickering during partial update. The piece of page to be updated looks first (mili)seconds raw and flickers afterwards. Obvious, CSS / JavaScript (I don't know) are being applyed with some delay. PrimeFaces renders at first script (encodeScript) with onContentReady and at second markup (encodeMarkup). Maybe could it cause a delay for rendering? I often do this by another way - I render script directly after markup without waiting if related content is ready. It works as well. I think, MyFaces does it in the same manner. What do you think?
Best regards.
Oleg.
onContentReady and partial update
PrimeFaces Cookbook (2. edition): http://ova2.github.io/primefaces-cookbook/ Learning Angular UI Development with PrimeNG: https://github.com/ova2/angular-develop ... th-primeng Blog: https://medium.com/@OlegVaraksin
-
- Prime
- Posts: 18616
- Joined: 05 Jan 2009, 00:21
- Location: Cybertron
- Contact:
The thing is as most of the components are widget oriented, markup just render simple stuff like a placeholder <div /> and the widget takes that div creates the actual DOM. So changing the order might have no effect.
Which components are you having with? If it is too disturbing, we can discuss improvements.
Still at some point due to nature of ajax and dom updates, flickering is inevitable as the real problem is DOM and how effectively browsers apply changes.
Which components are you having with? If it is too disturbing, we can discuss improvements.
Still at some point due to nature of ajax and dom updates, flickering is inevitable as the real problem is DOM and how effectively browsers apply changes.
Thanks Cagatay. I'm happy with all components. But p:accordionPanel... I can really see the plain HTML for accordion panel (with entire content) if this component is included inside of p:tabView (dynamic = true, cache = false) and you switch tabs. Plain markup (placeholders) appears indeed short-time, but I can see that clearly.
PrimeFaces Cookbook (2. edition): http://ova2.github.io/primefaces-cookbook/ Learning Angular UI Development with PrimeNG: https://github.com/ova2/angular-develop ... th-primeng Blog: https://medium.com/@OlegVaraksin
-
- Prime
- Posts: 18616
- Joined: 05 Jan 2009, 00:21
- Location: Cybertron
- Contact:
Ok, I see, as it is unobstrusive most like other components, the flicker seems to happen for less than a second. If we apply the styles when encoding the markup that would help for sure. I'll try look into this after the release. Oleg, can you create a ticket for this so we won't lost it?
Super! I've created a ticket http://code.google.com/p/primefaces/iss ... %20Summary
PrimeFaces Cookbook (2. edition): http://ova2.github.io/primefaces-cookbook/ Learning Angular UI Development with PrimeNG: https://github.com/ova2/angular-develop ... th-primeng Blog: https://medium.com/@OlegVaraksin
Do you think it would be possible to generate the markup with "visibility:hidden" and then, after the widget has been properly constructed and all the styles have been applied, to make it visible?
I suppose this won't go well with the concept of 'progressive enhancement' because, if the user turns off his/her JavaScript, then the component will remain invisible. But then again, there could be a special attribute on the JSF component which could be used to specify whether the markup should be initially visible or not. This would allow the programmer to decide whether (s)he wants progressive enhancement or flickering. (Just my $0.02.)
By the way, the flickering is very visible during Ajax updates. I've also been considering possible ways of removing it. Perhaps, constructing the whole widget in the background and, after having it fully constructed, replacing the current one with the new one. I think I will eventually dig into the source code and experiment with it but I'm currently overloaded with other tasks and I toy with PrimeFaces for a few minutes each day, as time permits.
I suppose this won't go well with the concept of 'progressive enhancement' because, if the user turns off his/her JavaScript, then the component will remain invisible. But then again, there could be a special attribute on the JSF component which could be used to specify whether the markup should be initially visible or not. This would allow the programmer to decide whether (s)he wants progressive enhancement or flickering. (Just my $0.02.)
By the way, the flickering is very visible during Ajax updates. I've also been considering possible ways of removing it. Perhaps, constructing the whole widget in the background and, after having it fully constructed, replacing the current one with the new one. I think I will eventually dig into the source code and experiment with it but I'm currently overloaded with other tasks and I toy with PrimeFaces for a few minutes each day, as time permits.
Really, DataTable, BreadCrumb and some other components flicker too. And this is because widgets "placeholders" are post-constructed with JavaScript (DOM modification). 100%. I think, we need to catch two points: after markup is ready and after widget construction. The first point is already catched with onContentReady. Markup can be done here invisible (display: none or better visibility: hidden to reserve needed place) and a custom content (e.g. rotated ajax indicator) can be displayed if nessesary. For the second point a new method has to be attached to the widget function passed to onContentReady. If widget function (responsible for construction) has been performed the attached function will be called. This new function does markup visible again and remove custom content if nessesary. It should work, I already done something like in a old Struts application.vesuvius wrote:Do you think it would be possible to generate the markup with "visibility:hidden" and then, after the widget has been properly constructed and all the styles have been applied, to make it visible?
I suppose this won't go well with the concept of 'progressive enhancement' because, if the user turns off his/her JavaScript, then the component will remain invisible. But then again, there could be a special attribute on the JSF component which could be used to specify whether the markup should be initially visible or not. This would allow the programmer to decide whether (s)he wants progressive enhancement or flickering. (Just my $0.02.)
By the way, the flickering is very visible during Ajax updates. I've also been considering possible ways of removing it. Perhaps, constructing the whole widget in the background and, after having it fully constructed, replacing the current one with the new one. I think I will eventually dig into the source code and experiment with it but I'm currently overloaded with other tasks and I toy with PrimeFaces for a few minutes each day, as time permits.
PrimeFaces Cookbook (2. edition): http://ova2.github.io/primefaces-cookbook/ Learning Angular UI Development with PrimeNG: https://github.com/ova2/angular-develop ... th-primeng Blog: https://medium.com/@OlegVaraksin
-
- Prime
- Posts: 18616
- Joined: 05 Jan 2009, 00:21
- Location: Cybertron
- Contact:
When you update a component like schedule that has a huge DOM, there will be a flicker for sure, there's no good fix for that as it expected behavior in my opinion.
We can try several ways though to improve it, one is removing onContentReady, it adds timers and checks DOM periodically if element is ready, maybe encoding markup first and then encoding script should work. That is something to try and must be tested on all browsers.
Other way is setting visibility to hidden and when client side rendering(DOM creation) is complete, making it visible, another thing to check to see how it looks.
Great to have your guys feedback. This is one active open source community.
We can try several ways though to improve it, one is removing onContentReady, it adds timers and checks DOM periodically if element is ready, maybe encoding markup first and then encoding script should work. That is something to try and must be tested on all browsers.
Other way is setting visibility to hidden and when client side rendering(DOM creation) is complete, making it visible, another thing to check to see how it looks.
Great to have your guys feedback. This is one active open source community.
Actually, tab switching in dynamic tabView remains the old tab content (it's displayed) and requestes a new tab content to replace the old one. It takes a little bit time and causes flickering. I think, the old tab content should be removed immediately and then (!) a new request should be sent. The flickering could be reduced by this way. Tested
PrimeFaces Cookbook (2. edition): http://ova2.github.io/primefaces-cookbook/ Learning Angular UI Development with PrimeNG: https://github.com/ova2/angular-develop ... th-primeng Blog: https://medium.com/@OlegVaraksin
-
- Prime
- Posts: 18616
- Joined: 05 Jan 2009, 00:21
- Location: Cybertron
- Contact:
But it should display a loading animation when loading the content? So maybe idea should be update first and then show the tab. I need to check the code to see what we are doing right now regarding the order.
-
- Information
-
Who is online
Users browsing this forum: No registered users and 32 guests