No – this is part of Stacks, not RapidWeaver.
Maybe – something similar could be added to Stacks.
But see the long post above about my week of lots of hardware testing. The real answer is: not sure yet.
Could this be achieved by using CALayers (double buffering)? This could actually be faster and more compatible if it works.
This answer is going to get pretty nerdy. Sorry – I try to answer in kind to the nerdiness of the question. And that question was 100% LOL
Stacks edit-mode is a “hybrid” view of both WebKit and traditional NSViews and CALayers. This speed-up relies on CSS inside of the WebKit parts. WebKit already extensively uses CALayers, caching, buffering, etc. – the trick doesn’t change any of that – but nudges WebKit into creating a single large CALayer for the entire scrollview – something it doesn’t normally do unless it really has to.
Why? If it’s faster, why wouldn’t WebKit do this all the time? I’m not a WebKit dev, but I think there are a lot of reasons a regular web page might NOT want to normally create such a big CALayer – any dynamic content will need to re- “blit” (copy) ALL of the pixels after each tiny change – shoving them from the CPU/RAM over to the GPU/VRAM – which is far from free. If you have to do that enough then this trick would slow down a web page.
But for our purposes in Stacks most of the dynamic interactive content (like text editing) is NOT part of the WebView. And since Stacks edit-mode doesn’t allow JS – this split is pretty set in stone.
We’re really getting down into the implementation details – but suffice it to say that this trick is pretty well suited to our little corner of the world. The long-standing implementation details of edit-mode naturally slot in to places where this trick works the best.
As you have stated, there are two problems including overloading the GPU and all the hardware limitations between different models.
There is a mechanism in the OS to handle this type of situation which is just using the old school method drawRect to blit to the screen. I spent a little time to create a prototype project to render to an off screen WebView and extract an NSImage of the entire view and then use drawRect to blit only that part which is needed for display. Scrolling was buttery smooth with no visual glitches. With this method the backingstore is kept in RAM and only spoon feed to the GPU through drawRect. The GPU saturation problem goes away and this will also solve the hardware limitation problems.
What I suggest is downloading the latest source code for WebKit and create your own modified version to give you the capabilities to redirect the output to an NSImage which you can use as the backingstore for the drawRect method. A modified WebKit framework would possibly open up other enhancements/optimizations you can use to increase performance of the editor.
For this to work properly, you’ll need to first sanitize your hands with alcohol-based hand sanitizer*, next gloves, next use an FDA-approved mask, plus socially distancing from social media.
Refrain from bad words.
*70% minimum. Or minimum 100 proof oral alcohol if you don’t want to get your hands dirty, in which case bad words are not only permitted but preferred.
I have had a few questions about Boost too, so I contacted Jonathan at 1LD.
Jonathan confirmed that the Boost stack needed to be present on each and every page to be accelerated in edit mode. He suggested adding it to a partial. That said, I have also had some odd behaviors since adding Boost to a partial that appears on most pages. The big quirk for me is that once the partial is opened for editing, I can no longer close it using the left arrow in the top-left corner of the edit screen. I have remedied this by clicking on another web page in the left panel. When I get back to the partial, I notice that my changes there were indeed saved, even though I had to exit the partial in an unorthodox way.
Second, I asked Jonathan about publishing with Boost. He said that the Boost stack does not have any publishable elements so it can essentially be left on a Stacks page indefinitely.
@firedude2894 Maybe I’m misreading you … but I have Boost only on a couple of pages: ones that really need a boost! It works great on them. I certainly don’t have it on every page and it works great.
I think that’s a good idea. Even though 1LD said it was fine to add Boost to a partial on every page, that’s how I got the odd behavior. I plan to just add Boost to pages as needed from now on.
I’ve just started to find RW8 has become very slow in Edit mode.
The only thing I think has changed for me has been that I’ve started using site images instead of warehoused images.
I’ve gone back to an earlier version of my project which uses warehoused images and Edit is as fast as it used to be.
Just wondering if this is something others have found.
I did quite a bit of “stress” testing and found just the opposite.
Site Images should be much faster in edit mode then “warehoused” images. Site images are loaded from your local hard drive, remote images (aka warehoused) would have to be loaded from your internet connection.
Even the fastest internet connection vs the slowest hard drive, the hard drive always should be many times faster.
There is also an internal deference that @isaiah explains in one of his videos. The Site Image stack basically is kept in memory.
I did a stress test a while back and found loaded identical images (gigabytes Worth of them) and found the site image version to be much smoother (no jitters) and faster in edit mode. Same exact images on the page with “warehoused” Images became so slow and jittery that it got to the point it was almost impossible to edit.
Very interesting. Very helpful.
Yours is certainly a more robust test than my little effort.
So I’ll persist with site images and look elsewhere for causes of edit slowness.
LOL
