Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
CSS3 scale property produces bad quality on lower-than-config-resolution windows #609
There are several other issues in this repo that deal with sizing/scaling a slide/step to fit into the browser
As far as I understood the current implementation the scale value will be
You can see that the scaled scene has more aliasing artifacts than the native resolution image.
I tried to accomplish an always-fitting-slide without using the CSS
This approach would make a presentation fully independent to the users browser window resolution. The translate calls that are done by
Please add comments for further investigation of this issue.
This is an interesting study you've made. And indeed it seems vw and vh would be very useful units for creating slide shows, since the idea with impress.js is to scale contents of a slide to match screen size.
I think one question I have from reading your above entry: It's possible in impress.js, that you will see content from other slides in the background of the current slide. Example: http://impress.github.io/impress.js/#/its-in-3d They may have a different scale (so different size). How would content on such a slide scale, if it was using vw and vh?
I thought about your input and came up with another proof-of-concept implementation that shows how to implement a vh/vw-based presentation framework.
I noticed 2 things while implementing this:
I know that there are tricks to optimize reflows but I don't know how to apply them (if even possible).
Also the new design forbids the use of
Feel free to play around with the constants - it's quite funny to see how everything automagically adopts (or explodes)
I added some transparency to the slides and the rendering performance is really bad...
I think a combination of the
During the transition of slides, the old
We have to be careful on which DOM element we apply the transformation. What we don't want is one big framebuffer texture that scales all slides as this will consume huge amounts of VRAM which may not be applicable on all PCs. Instead we want multiple smaller framebuffer textures that get updated independently (e.g. per slide).
After the transition of slides the above shown vw/vh approach should be favored instead of
The challenge is to integrate
An alternative solution would be to implement the
EDIT: I forgot to mention that the performance drain (the reflow) only occurs when the
referenced this issue
Apr 23, 2017
Thanks for looking into this more. The limitations of scaling are annoying users regularly. (As you can see from above referenced issue about scaling SVG.) It would be great if there was a solution. I think your results are encouraging, although it is not clear to me if a solution along these lines will be feasible to implement in impress.js in a backward compatible way? (I'm really a backend developer - what you're doing is definitively stretching the limits of my knowledge.)
Isn't this what impress.js currently does? And if we want all slides to be potentially visible during a presentation, isn't it logically necessary to re-scale all of them all the time?
This is the reason bartaz has been hesitant to officially support it on phones, because it could easily run out of RAM. One patch proposed a solution (for mobile devices) to only show the previous, current and next slides to limit RAM consumption. For more advanced presentations, that want other slides to be visible - such as in the background of the current slide - this is quite limiting of course.
Yes I think this is what impress.js currently does. The thing that I wanted to point out is that we have to be careful to not remove this feature.
I thought of something like this for a transition from slide
This avoids a reflow for every transition frame but only reflows at the beginning of each transition. During the transition itself the hinting/antialising artifacts will still appear but I think this will barely be noticed by any user.
I implemented the above approach
Problems that occured while implementing this were:
To solve the above problems:
Cool, thanks for sharing. I will try your solution at a later point, as I'm very interested in solving this issue (one way or another).
Related to solution requiring lots of RAM, kind of related is the mobile plugin, which allows you to
Note, it could also be useful to know that impress.js sets a class on body element, which has the name of the active slide. For example, when active slide is "step-1":
We're working on merging my stuff into impress.js repo, so expect the mobile plugin to show up some weeks from now.
I tried to fix the 2nd problem and ran in the following issues:
When implementing solution
When implementing solution
I think my current implementation will work well for presentations that use small amounts of 3D (e.g. not my example
Issues that remain:
Thanks for your work on investigating this issue. Partly thanks to following you, I've found out a way to get non-blurry background images also with current impress.js. Here's a demo I did to explain how to make a non-blurred background and the pro's and con's of both ways: http://openlife.cc/blogs/2017/october/impressjs-howto-slides-over-background-image
As you've discovered, having a large background image that's also sharp, will use up HUGE amounts of RAM. In fact, images often failed to load for me. So I'm not sure that we could switch to such a solution in impress.js in general, rather it is better that the user use their own CSS to achieve this if they want to. This way they can also manage when they want to consume that much RAM and when not.