jshanman wrote :[color=blue]
> Gérard Talbot wrote:[color=green]
>> 1st recommendation: never set y < 32 . Otherwise people with modest
>> system will crash.[/color]
>
> I wouldn't set it to anything below 250ms
>[/color]
A good decision then!
[color=blue][color=green]
>> 2nd recommendation: use a proper event listener, not an interval. The
>> script will be triggered on that event, not all the time. It makes a lot
>> more sense.[/color]
>
> Can you give me a simple exampe of a "proper event listener".[/color]
(after checking a bit more your code,..) Your code does that already:
addEventListener is doing it.
[objectReference].on[eventtype] = functionName;
is the general syntax for non DOM2 event browsers.
[color=blue]
> I am considering just placing the next setTimeout at the end of the
> function that re-draws the labels in the timeline, that way, it won't
> try to move the timeline again until it has completly finished
> moving/drawing it the first time.
>[color=green]
>> Addendum: the script is that start autoscroll timeline, right? Then you
>> may consider something else, a better alternative... pretty sure there
>> could be something better.[/color]
>
> An alternative as in something other then the Google Maps API for the
> timeline? Or what?[/color]
Regarding setTimeout
"Speaking of animation, one of the most common techniques for animating
elements is to use a timer with window.setTimeout to position an element
on the page incrementally. A quick tip: **Use as few timers as
possible.** Timers consume valuable system resources, and the behavior
of multiple timers, all working together, will greatly vary on
differently powered machines. A way to animate multiple elements, while
minimizing timer use, is to employ a single main loop, powered with a
single window.setTimeout() call. In that single loop, keep a list of all
elements you need to manipulate. Loop through that list with each tick,
and perform your required move."
http://msdn.microsoft.com/library/d...ml/dude1201.asp
I've considered writing my own interface for the[color=blue]
> timeline but I will just be re-writing basicly the same code, just
> minus all the lat/long stuff.
>[/color]
I examined your page code some more: it would take me quite a lot of
time to understand all of its internal logic, intricated calls and
inter-dependent functions. I could do it but it would take me quite some
time.
Mozilla-based browsers still have performance problems with some DHTML
redrawing a page (like moving objects, needing to be redrawed). There
are ways to avoid such performance problems. But the browser is still a
bit more sensitive to DHTML performance than, say, MSIE 6.
[color=blue][color=green]
>> You definitively need to fix your markup code
>> and CSS code before going over optimization of javascript/DHTML.
>>[/color]
>
> I know, I know, I'll get to that before I put the application in beta
> status : )[/color]
This is not the normal order of developing a page then. You should first
develop the content, then its structure, then the markup code (and
accessibility), then the style info and then, only then, the script:
that's the best way to develop a webpage, even a very intensely
dynamic/javascript one.
[color=blue]
>[color=green]
>> It doesn't respond slowly: it can't respond (overload, over-burdened),
>> it can not cope with the script demand. Again, consider 1st and 2nd
>> recommendations.
>>
>> 3rd recommendation: always define the radix when using parseInt:[/color]
>
> The values that go into those parseInt come from a select, so I define
> the only values that they can be. But I will do as you suggest by
> putting a ", 10" in the statement.
>[color=green]
>> I congratulate you on using meaningful, intuitive, self-explanatory
>> variable identifiers. This is good for debugging and for reviewing by
>> others who may not know what your code do or is about.
>>[/color]
>
> With all the javascript on that page, I would be lost the day after I
> programmed something if I didn't do that...
>[color=green]
>> 4th recommendation: use a button since this is a command; do not use a
>> pseudo-link (a link) since the link goes nowhere. Avoid href="#"
>> everywhere.
>>
>> <button type="button" id="btnStop" onclick="Playing = false;
>> clearTimeout(PlayTimer); PlayTimer = null;">Stop</button>
>>[/color]
>
> Just out of curiousity, why should it be avoided? Are there browser
> issues with that, or is it just best practice?[/color]
Best practice for many reasons:
- if javascript support is disabled or inexistent, then the link remains
functional when a link is used; <a href="#" ...> is always a mistake, is
always a webpage design mistake.
- search indexing engines won't waste time with a <button> but will
index for wrong reasons an <a href="#" ...>
- mouse gestures, accessibility applications, etc.. won't waste
time/confuse users/frustrate with <button> but will with <a href="#" ...>
- a link is a link and should be a link and load a referenced resource
into the same webpage otherwise you're misusing markup semantic;
therefore, a link will behave as expected and as a link in other media
and other web-aware applications... which may not be a visual browser
- etc.
The only reason I've[color=blue]
> avoided buttons this far is because they take up more pixel space the
> just text links.
>[color=green]
>> 5th recommendation: Absolutely and positively consider to validate your
>> markup code and CSS code and to use a strict DTD: the page has 284
>> markup errors and the page takes well over 40 seconds to load on a
>> dialup connection.
>>[/color]
>
> I don't know if I will use a Strict DTD, but I will validate once I get
> the bulk of the program working. I already know this application isn't
> going to be very dialup friendly...[/color]
Maybe the nr 1 problem you have is non-optimized javascript right now;
but you first should start with/be addressing the markup code, then CSS
code and then address the javascript code. In that order.
The goal is to have a page like yours to be loading itself faster; your
webpage should not take so loong to load. The page should load very fast
if javascript is disabled.
[color=blue][color=green]
>> 6th recommendation: avoid innerHTML when dynamically setting the node
>> value of a text node. innerHTML is relatively slow and system resource
>> demanding.[/color]
>
> As opposed to ??
> I have lots of innerHTML... What would you recommend I use instead?
>[/color]
You can use the general-purpose and cross-browser function
function ChangingElementText (Id_Attribute_Value, newText)
I proposed at this precise url:
https://bugzilla.mozilla.org/show_bug.cgi?id=74952#c120
or (best, IMO) you can use
objRef.childNodes[x].nodeValue = strNewText;
where x is the indexth textnode you want to change for non-DOM3
compliant browsers and then use textContent for DOM3 compliant browsers.
Opera 9 and Mozilla 1.5+ (Firefox 1.x, NS 7.x) all support textContent.
So, first check for object support of textContent, else, use
childNodes[x].nodeValue = strNewText
innerHTML versus nodeValue performance comparison
http://www.gtalbot.org/DHTMLSection...sNodeValue.html
There is even an article explaining/demonstrating that recourse to
innerHTML is slower for changing a textnode at msdn.
If you know well what you want to change, then you can safely rely onto
DOM2 CharacterData methods which are all supported by MSIE 6, MSIE 5.x
(except 1), Opera 7+, Firefox 1.x, Mozilla 1.x, Safari 1.2+, etc.:
DOM level 2 CharacterData Interface tests
http://www.gtalbot.org/DHTMLSection...racterData.html
Gérard
--
remove blah to email me
