4 ms·
In GDI era caret bar ( that's not cursor, sic!) was rendered as by simply inverting pixels (InvertRect() call) inplace in video frame buffer. Very cheap operati
by c-smile 10y ago
In GDI era caret bar ( that's not cursor, sic!) was rendered as by simply inverting pixels (InvertRect() call) inplace in video frame buffer. Very cheap operation that does not require redrawing and run of any other code.
With the GPU the only viable option for rendering blinking caret is to redraw the whole window. That's why it takes so much CPU as Chrome uses mostly CPU based rasterizer.
But redrawing the whole window in GPU is not that bad if the renderer is capable of caching GPU objects while rendering.
Here is what happens in Sciter (https://sciter.com https://sciter.com) while rendering blinking caret in screen of similar complexity (editor with syntax hihglighting):
https://sciter.com/images/sciter-caret-cpu-consumption.png https://sciter.com/images/sciter-caret-cpu-consumption.png
As you see it CPU consumption is near to zero.
- phkahler 10y ago>>In GDI era caret bar ( that's not cursor, sic!) was rendered as by simply inverting pixels (InvertRect() call) inplace in video frame buffer. And on an old 8-bit system, blinking a cursor involved toggling one byte (character code) in video RAM. How far we have come...
- jblow 10y ago"With the GPU the only viable option for rendering blinking caret is to redraw the whole window." Sorry, that is plainly false. There is nothing preventing you from treating an offscreen buffer just like any other buffer of non-dirty pixels. Treating the back buffer that way is slightly less conventional but is still just fine.
- c-smile 10y ago> There is nothing preventing you from treating an offscreen buffer just like any other buffer of non-dirty pixels. You need: 1. ability to invert pixels by CSS/JS. No such feature in principle. For many reasons. 2. Even if you will be able to invert those pixels in offscreen bitmap you need to send that window's offscreen bitmap to CPU on each caret blink. You can use tiles - so do partial CPU->GPU data transfer but still. 3. If you use offscreen buffer you are almost always use CPU rasterization. CPU rasterization is O(N) operation, where N is a number of pixels. On high-dpi monitors (200dpi...300dpi) number of pixels is 4...9 larger than on "standard" 96dpi monitors. And CPU stay roughly the same last 4-6 years. So if you want your app to run on modern hardware - GPU is the only viable option for rendering - forget about offscreen bitmaps and the like.
- jblow 10y agoNone of the 3 things you said are true. I recommend you get some experience in rendering before you mislead people too much with these kinds of comments. In reality the problem is trivial, you set up a scissor rect (or explicitly mask the pixels in your shader) and then render only stuff overlapping that square. You don't need to invert the pixels for it to be fast; you can render an arbitrarily nice cursor effect.
- c-smile 10y agoI am not sure I understand why do you need clipping at all to render rectangular caret bar (note: cursor is a different entity in UI professional jargon). What exactly you want to be clipped out?
- deleted 10y ago[deleted]
- jblow 10y agoI am assuming that your caret bar may be overlapping text in some way, or that there is a background bitmap that you might be alpha-blending against, etc. Basically I don't want to make an assumption that might break if the UI gets nicer. The case of a strictly opaque strictly rectangular non-antialiased non-smoothly-moving bar does not seem very interesting or nice-looking.