as there is less [ultrasound] around in a normal environment.
Is that true? How do you know? I hope this claim isn't based on the fact that you normally don't hear any ultrasound in your normal environment...
I for one can think of a crapton of stuff in my 'normal environment' that likely emits ultrasound, first and foremost every switching PSU (except the crappy ones that switch in the audible spectrum, producing a sound like a muted TV....)
You just gave a verbose version of exactly what I said.
To me, it sounded like you were largely conflating double buffering and vsync, or implying that people came up with double buffering primarily to be able to vsync. I pointed out that double-buffering and vsync are entirely different concepts (also working on different levels). If you're rendering fast enough, there would be nothing stopping you from doing vsync with a single buffer. People don't do that not because i's a stupid idea (it is, of course), but rather because by the time vsync became a thing, double buffering was already established practice (and frankly the only way to obtain flicker-free animations anyway). Yes, it is one (among many) ingredients to get decent vsync.
It does not make the concepts 'related' in my book, though, similar to how I don't consider, say, a 'bottle of milk' and 'electricity' to be related concepts, even though likely a lot of electricity went into the whole sequence of events that ended with a bottle of milk standing in my fridge.
Did you not even realize I wasn't the GP poster and not continuing their argument?
I was aware that you're not the person I initially replied to.
I'll give you the benefit of the doubt and assume you're trolling. Since you're doubtlessly going to deny then, I'll follow up by recommending to re-read my post real slow. That and perhaps familiarize yourself with the basics of the topic you're trying to discuss.
The point is to only draw an image once it has been completely rendered. Synchronizing that with the display's refresh rate (vsync) came way later. With no double-buffering you get horrible flicker because you're modifying the frame buffer while the display is drawing it, so what gets drawn are partial images, or the frame buffer right after it has been erased for the next image, etc.
Sorry, but there's more to readability than consistent indentation. I'm pretty sure I'm not the only one who has seen truly horrible python code. Running in production, of course.
protip: even if your wild guesses were right, you'd still be the one spending your time following the "nerds" on the internet to anonymously tell them what failures they are, while you could certainly (cough cough) bang the cheerleader instead. bitter-sweet irony.
Slashdot Mirror
carries less hiss and clearer sound
Hahahahaha. Yes, sure. As long as you get a perfect signal, anyway.
as there is less [ultrasound] around in a normal environment.
Is that true? How do you know?
I hope this claim isn't based on the fact that you normally don't hear any ultrasound in your normal environment...
I for one can think of a crapton of stuff in my 'normal environment' that likely emits ultrasound, first and foremost every switching PSU (except the crappy ones that switch in the audible spectrum, producing a sound like a muted TV....)
Tor is transport.
But 2017 is already the year of the Linux desktop...
How can the leading asteroid be trapped?
Maybe because they have tried targetting more advanced audiences, but no one seemed to be home?
Scheduling. You would have to [...]
Hence "if you're rendering fast enough", and the part that you missed when jumping from that sentence to the 'reply' button.
You just gave a verbose version of exactly what I said.
To me, it sounded like you were largely conflating double buffering and vsync, or implying that people came up with double buffering primarily to be able to vsync.
I pointed out that double-buffering and vsync are entirely different concepts (also working on different levels). If you're rendering fast enough, there would be nothing stopping you from doing vsync with a single buffer. People don't do that not because i's a stupid idea (it is, of course), but rather because by the time vsync became a thing, double buffering was already established practice (and frankly the only way to obtain flicker-free animations anyway). Yes, it is one (among many) ingredients to get decent vsync.
It does not make the concepts 'related' in my book, though, similar to how I don't consider, say, a 'bottle of milk' and 'electricity' to be related concepts, even though likely a lot of electricity went into the whole sequence of events that ended with a bottle of milk standing in my fridge.
Did you not even realize I wasn't the GP poster and not continuing their argument?
I was aware that you're not the person I initially replied to.
I'll give you the benefit of the doubt and assume you're trolling. Since you're doubtlessly going to deny then, I'll follow up by recommending to re-read my post real slow. That and perhaps familiarize yourself with the basics of the topic you're trying to discuss.
The point is to only draw an image once it has been completely rendered. Synchronizing that with the display's refresh rate (vsync) came way later.
With no double-buffering you get horrible flicker because you're modifying the frame buffer while the display is drawing it, so what gets drawn are partial images, or the frame buffer right after it has been erased for the next image, etc.
I don't know if normally without V-sync just one buffer is used
No. Double buffering (or even triple buffering) is a decades-old thing that has nothing to do with vsync.
Why is the difference between 16:9 and 16:10 such a big deal?
Maybe it is whatever crap you have installed? Ask your package manager who a particularly large directory or file belongs to.
System folder my ass.
Hey, long time no see.
Seems par for the course
What, is the trolling business closed over the holidays? Fucking amateur.
if you remember Windows 3.11, Windows wasn't great
Sure wasn't, but compared to what came after...?
Your ideas are intriguing to me and I wish to subscribe to your newsletter.
Yep. The primary modus operandi of *DOS was in fact denial of service.
A thousand times this.
Unfortunately, getting that right requires a functioning brain. fnj doesn't seem to have one.
Sorry, but there's more to readability than consistent indentation. I'm pretty sure I'm not the only one who has seen truly horrible python code. Running in production, of course.
look, trolling is a bit like DDoS via amplification. If you're sending (writing) more than you're getting back, you're doing it wrong.
protip: even if your wild guesses were right, you'd still be the one spending your time following the "nerds" on the internet to anonymously tell them what failures they are, while you could certainly (cough cough) bang the cheerleader instead. bitter-sweet irony.
Project much?