| Thanks for the answers. This raises even more questions! It sounds like you're allowing a hidden DOM to be rendered by the browser and then you're going to render it again in a canvas element? Is the DOM "live" in the browser, so to speak? I am very interested in seeing more details! The reason I was asking about scrolling / invalidation was just to try and guess how you're doing it. Like, if you are rendering all the text in a canvas and you have a hover or click state that requires a change to what's on screen, are you re-rendering the whole canvas or working out the minimum clipping rectangle or what. Broadly, my concern is this: When people re-implement stuff that already exists in the browser or operating system, they miss things. Or they make it work the same in every browser, when browsers and operating systems are different, and people choose them for a reason. Off the top of my head: - If you render text yourself then you don't get the subpixel / hinting behaviour or kerning that's distinctive to the OS (or browser engine). This looks out of place, and you discard a lot of hard work and performance tuning that has gone into making the text look good. - For example, maybe you hijack the command for "find". Do you hijack ctrl-F and F3 on Windows? cmd-F on Mac? What about Linux? What about "find in page" menu item on my Android phone? On a Mac, cmd-G is "find again". That may be different on Windows. - I use shift-space to scroll up. Cmd-up to scroll to the top of the page. On Windows that's the 'home' key. Did you think of that? - If I double-click I can use shift-left and right to select characters. Shift-alt-right to select words. Shift-page-up to select to the top of the page. Triple click to select a paragraph. Right-click to read a paragraph out-loud with speech synthesizer. Command-click to bring up a context menu. Double-click and drag to select multiple paragraphs. These are standard Mac OS things, nothing special. I am not asking "have you thought of these?", I am pointing out that they are different from platform to platform, and exist for a reason, and you will find yourself reimplementing a platform-in-a-platform. And it's a constant race to copy and maintain compatibility, when the purpose of an OS and browser platform is to allow the creator to focus on building on top of those abstractions, not to re-implement them. Or you will be removing functionality from end-users and making the sites worse to use. I hope you don't find this too negative. These are big issues, and your project touches on them. |
2) Yeah the scene graph would tell the renderer to only render the bare minimum with a clipping rectangle. Re-rendering the whole canvas is only done when some sort of "global" change like scrolling occurs.
3) I agree with you completely on this one. There are ways to do it for sure but they require some tinkering. Like I said in another reply, one of the main goals is to keep everything consistent. And actually, with the newer browsers the text rendering has actually been really good canvas.
4) For the set of questions with hotkeys, I do not intend to remove any functionality from end user. I never really thought about these things so thanks a lot, now I can keep them in mind. I cannot give you a specific answer as of right now, but I do know there are ways of capturing text selection and keeping that selection independent from how the user tries to highlight text.
I don't find any of this negative, on the contrary I am thankful for the feedback.