OSDev.org

http://www.trackze.ro/wsbe-4-get-clippy/

This week, we start looking into clipping, the core element that makes a non-compositing window manager run at a usable speed under real world conditions, and we begin incorporating the core of a simplified clipping system using rectangles into our drawing context.

Great tutorial
Not sure if clipping will speedup the rendering process that much.
I added it in the past, but using SSE optimized memcpy resulted in faster window movements then with clipping. (Due to the overhead for the small rects)
But this is for sure faster when using a rather simple memcpy

Hey, thanks for checking it out! Seeing site metrics is one thing, but hearing from actual people that they gave it a look absolutely makes my day.

But, yeah. You're totally not wrong, and really if it isn't obvious yet I'm mostly doing things along the lines of a light clone of the OG Windows/Classic Mac OS model. My arbitrary intention is to be somewhat of a demonstration of, very broadly, how things have been done 'historically'.

My approach is probably(definitely) a bit silly. But then again, so is this whole project.

jojo wrote:Hey, thanks for checking it out! Seeing site metrics is one thing, but hearing from actual people that they gave it a look absolutely makes my day.

But, yeah. You're totally not wrong, and really if it isn't obvious yet I'm mostly doing things along the lines of a light clone of the OG Windows/Classic Mac OS model. My arbitrary intention is to be somewhat of a demonstration of, very broadly, how things have been done 'historically'.

My approach is probably(definitely) a bit silly. But then again, so is this whole project.

Nah, even if the project dies, you learned alot and learning stuff is never bad.
This will help everyone who does not want to spend too much time with optimizing memory funcs or who simply cant use it (dif arch).

Manged to find this before it was posted in here, felt like . I like that you started using GIFs. It was a bit harder to understand it, but when you take a look at the code you can see what is going on. Are you getting any flickers when moving windows? I think I'll be implementing this very soon. Waiting for the next part. I think you should really consider implementing two buffers early on. Since it would only draw the screen once per full update, so it does not redraw it every single time something changes. I agree with Ch4ozz. Great tutorial as always.

Hey, octacone, thanks as usual! I figured if anyone would find it early it would be you.

Yeah, this one is a bit dense -- which is, in itself, one of the reasons I wanted to make it a bit more visual. Also, one of the reasons it ended up being a day late this time (my bad).

As far as double-buffering, check this out:



That's called screen tearing, right there. Because GDI, by default, doesn't give a single damn about timing. In the windows model as it stands to this day, of course excepting when you're running with that newfangled compositing turned on, screen updates happen directly to the screen (via whatever display driver GDI is running through) as soon as they possibly can.

It's true that you can get some fancy transparency effects and eliminate tearing if you go with compositing locked into a whole-screen double-buffer flip on VSync. And it's totally the way of the future/present. And it looks like doing so at a decent refresh rate in software-driven VBE is actually possible if you can write a good optimized memcpy().


But we're doing things the old way.

Because.

@jojo
I have never seen that amount of tearing. What is going on, underpowered CPU? I have a fairly old computer and still I can't reproduce that effect. Only when moving my windows super duper fast.
So can an improved memory copy function really make flicker go away? Everyone loves fluid graphics so do I. It is like 10 thousand times easier to work and to code a GUI that does not flicker. Also I noticed that the flicker goes away with the speed. So for example: 2012 CPU = 10 flickers per second, 2015 CPU = 1 flicker per second. So that means that the CPU directly affects the performance. This is a really interesting topic because it has multiple solutions.

octacone wrote:@jojo
I have never seen that amount of tearing. What is going on, underpowered CPU? I have a fairly old computer and still I can't reproduce that effect. Only when moving my windows super duper fast.
So can an improved memory copy function really make flicker go away? Everyone loves fluid graphics so do I. It is like 10 thousand times easier to work and to code a GUI that does not flicker. Also I noticed that the flicker goes away with the speed. So for example: 2012 CPU = 10 flickers per second, 2015 CPU = 1 flicker per second. So that means that the CPU directly affects the performance. This is a really interesting topic because it has multiple solutions.

I have a fairly decent PC (FX-8350, GTX 970) and this always happens to me in Windows. I feel that v-sync is a silly hack that doesn't really work properly and that FreeSync/GSync is the way forward.

This only happens when you use the old windows basic design.
The "new" aero and the new win 10 reworked GUI works perfectly.
Im not sure why they didnt fix the tearing artefacts in the older basic design.

Also my OS seems not to flicker even on real hardware, and with VBE I dont have any interrupts for the screen refresh anyways.

So that means that the CPU directly affects the performance.

Of course, when you're doing your drawing via the CPU.

If you're drawing using the CPU, then the faster the CPU goes the less time your framebuffer redraw will take. Meanwhile, the only way to not have flicker at all is to have all changes to the screen made entirely within the span of the vertical blanking interval. Since we're basically doing a framebuffer update at random, we can only express the frequency of tearing in terms of the odds of our framebuffer redraw not landing perfectly into the vblank period without spilling out. Obviously, if our CPU is very slow and takes more than the vblank time to do the drawing then you're guaranteed to have a 100% chance of a tear somewhere on the screen since there's no time in vblank that the drawing can start while still ending within vblank. However, as soon as that time drops to <= the vblank time, there is a possibility that we'll get lucky and have our drawing start and end in vblank. The odds that our redraw happens to begin during a vblank will always be exactly the same, but the less time that the drawing takes (the faster the CPU is) the higher the odds that if it does start during vblank that it won't fall out the other end of it.

That said, those odds are always going to suck since, to begin with, the monitor is being refreshed about 95% of the time and vblanked about 5% of the time.