gnash-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[6]: [Gnash-commit] gnash ChangeLog gui/NullGui.cpp


From: Udo Giacomozzi
Subject: Re[6]: [Gnash-commit] gnash ChangeLog gui/NullGui.cpp
Date: Sat, 7 Jul 2007 19:30:14 +0200

Hello Martin,

Saturday, July 7, 2007, 6:41:44 PM, you wrote:

MG> 2007/7/7, Udo Giacomozzi <address@hidden>:
>> it's just 5 lines of code... don't we have other problems?
MG> Of course. I was just having a rant because Gnash is full of awful
MG> code and I hate to see more of it growing like fungus :).

I dislike endless loops too, but sometimes (when the loop is very
short) they can make the code more readable IMHO.

MG> I
MG> particularly liked the
MG> switch (foo) {
MG>   case 0x00: bar = 0; break;
MG>   case 0x01: bar = 1; break;
MG> ...
MG> for all possible values of foo :O/

This was real code?? :-O


MG> You accurately describe how that effect is achieved on a certain
MG> multitasking operating system, but that's not the same as the
MG> function's meaning.

Hmm, I referred to the description of the Linux kernel docs itself
(some documents about the scheduler internals, including 2.6
preemptive kernel).

But whatever, using usleep(1000) should be fine in any case.


>> AFAIK all normal i386 systems use a 100 Hz timer

MG> That used to be true in linux 2.2 but now in Linux it is a parameter
MG> you set when you compile the kernel, and it suggests values of 100,
MG> 250 and 1000Hz where "normal" is now 250Hz for desktop systems (for
MG> better mouse motion response I presume)

AFAIK in kernel 2.4 this was still a hard coded value, but I could be
wrong.


MG> How about sched_yield() ? It's an optional POSIX feature that is meant
MG> to do exactly what you describe, rather than doing that by chance on
MG> certain non-conformant operating systems.

Interesting function. Strange I've never seen it in any code. As long
it is widely available, it sounds good.


>> while (1) { }               // burns CPU
>> while (1) { usleep(1); }    // process will show 0.00% CPU usage
MG> Yes, that does surprise me.

You're not surprised anymore now, I hope? :)


>> That could be done, but would not match the PP behaviour
MG> "PP"?

Proprietary Player, ie. Adobe player


>> Any user would notice the difference, so I don't think it's a good idea.
MG> It's better than the visuals lagging behind the sound. Users notice
MG> that far more!

I'm sure PP is not skipping frames (except for Video maybe). When the
CPU is too slow to handle the rendering, then frame rate decreases
(just like it happens with Gnash).

Both methods have their dis/advantages.

However, I'm not sure what sounds problem you are talking about since
normally sounds samples are synched to frames...

Udo





reply via email to

[Prev in Thread] Current Thread [Next in Thread]