dynapi-dev — List related to the current DynAPI Core development

RE: [Dynapi-Dev] Freeing Memory

[Pascal <pb...@oi...>]

Ok, it then seems I misunderstood the complete discussion.. but I don't
think everyone was on the same thinking-plane as Robert is, and some other
people (the few that actually reacted) might have thought the same way I
have: the plan of creating a new API from the ground up.

This is something I don't think has any potential what so ever (just
restating my point here) for the reasons I posted in the other mail.

I'm all for cleaning up the current code, but not for changing things around
"hoping" it will end up faster and lighter (I strongly believe it won't)

To reply to Raymond's  disullisioned problem  quote:

"To be honest I was a little disillusioned with the overall response to what
I was proposing.  And I'm certainly not interested in expending a large
amount of my time for nothing."

That's just part of my problem as well.. people seem to like discussing
things (I'm one of them) but almost nothing is being done!  This is what I
see as the biggest problem with the DynAPI2.  I have now read numerous posts
of people saying that they fixed bugs, created great add-ons.. great, BUT
SHOW US.   don't tell us you did it, and it works, and it's better..give it
up! (read the LICENSE agreement).

Everyone saying that the current API could be improved alot is correct, but
not for the reasons they give, but for the fact that if everyone would start
sharing there work more it would have grown faster.

Ofcourse, Raymond, your ideas are great and planning things is fine (as long
as we're planning the enhancement and continueation of THIS api).. but if
planning is all that's being done by people, then I'd rather not
participate...and I fear that that's the case (as usual)


"<emotes> flips blow torch in the air and extends the hand towards the rest
of you all."

lets see who will reach towards it then, just don't get disillusioned
again...


Pascal Bestebroer (pb...@oi...)
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Jordi -
> IlMaestro
> - Ministral
> Verzonden: woensdag 21 februari 2001 10:25
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] Freeing Memory
>
>
> Amen. However Pascal I don't think anyone pretends to redo
> the API. We should
> blame Raymond ( as usual :) ) because he introduced the 3 in
> the name and made
> it all look scary.
>
> When we're saying DynAPI3 I understand we're meaning DynAPI2
> with better and
> cleaner code, not a new API.

Re: [Dynapi-Dev] Freeing Memory

[Jordi - I. - M. <jmi...@or...>]

The audience is listening.

Try not to let these not-so-enthusiastic responses get into you. It happens to
everybody: posting the results of many hours of work, expecting at least not to
be ignored, and then receiving nothing but silence.

I believe you're going the right way. Usually people post to disagree because
they feel things are moving towards somewhere they don't like and/or is of no
interest for their personal usage of the API. When things go right then people
is most likely to adopt a confortable attitude.

He who remains silent concedes.

Raymond Smith wrote:

> <emote> pulls out blow torch, flick and ignites a cold blue flame....
>
> First off, I can understand your passion, and if you go all the way back to
> the very first "lets stop and think about it first, then act" post you will
> see that above alpha-next-generation-anything was finish up DynAPI2.
>
> Secondly, beginning discussions (which you should definitely be involved in)
> on the planning stages of the next generation of "this" API is certainly
> appropriate at this time.  The format that was presented was one of
> brushstroke self-appraisal with an eye towards what we would like the next
> evolution of this API to be capable of.
>
> Not one mention of "abandon and run" removing the potential for backward
> compatibility.  Which I think should be a serious consideration in this
> "planning" stage.
>
> At this stage not a single "anything" has been agreed upon.  There have been
> lots of discussions related to super-class this, client-side that.  I only
> interceded to try and frame and consolidated these "loose" discussions into
> a more productive format based on mutual collaboration.  Hence references to
> UML, whiteboards and the need to really think before we type.
>
> But...
>
> Based on your most recent rock-throw I personally would like to see this
> discussion focus on one thing.
>
> What we would like to do.
>
> Personally, I am looking to the Pascal's and Rainwater's for leadership
> here.  I'm only attempting to contribute my time and energies to help push
> the ball along.  I've posted 3 times with queries for "input" and received
> little in the form of response.
>
> One thread asked which of 3 distinctly different endpoint objectives we have
> for this API.  Attached:
>
> (1) A set of surface enhancing widgets for general layman use.  Menu,
> windows, navigation devices.
> (2) A series of linkable components (server and/or client) that can manage
> and present information dynamically within the library of server-side
> widgets(1).
> (3) Both.  An API that allows the generalist to enhance their site using the
> API that also has hooks developed into it that allows a more serious
> implementation embracing the whole information interchange circuit; client
> to server-side.  As Robert has pointed out these "hooks" could be developed
> to allow the user language implementation  flexibility.
>
> Answer this question will go along way to adding a lot of clarity as to what
> next-steps in this Open Source Forum, based on and proposing to extend
> DynAPI2.
>
> To be honest I was a little disillusioned with the overall response to what
> I was proposing.  And I'm certainly not interested in expending a large
> amount of my time for nothing.
>
> So,...
>
> Lets decide.  I think your negative whiplash reaction was a little
> premature, but knowing the passions of Pascal I understand it.
>
> <emotes> flips blow torch in the air and extends the hand towards the rest
> of you all.
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

Re: [Dynapi-Dev] Dynamic Loading.

[francesco A. <fa...@we...>]

i don't understand......


----- Original Message -----
From: "Darin Kadrioski" <dka...@ef...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 8:11 PM
Subject: RE: [Dynapi-Dev] Dynamic Loading.


>
> say fellas, how do i unsubscribe from the list?
>
> -----Original Message-----
> From: Doug Melvin [mailto:do...@cr...]
> Sent: Tuesday, February 20, 2001 2:01 PM
> To: dyn...@li...
> Subject: Re: [Dynapi-Dev] Dynamic Loading.
>
>
> and what site would that be?
> ----- Original Message -----
> From: "francesco AGATI" <fa...@we...>
> To: <dyn...@li...>
> Sent: Tuesday, February 20, 2001 4:55 AM
> Subject: Re: [Dynapi-Dev] Dynamic Loading.
>
>
> > HI,
> >
> > see this site for alterative loading dynamic data
> >
> > work only for IE5+,NS6,Mozzilla, not IE mac, not NS4
> >
> > ----- Original Message -----
> > From: "Nuno Ferreira" <nun...@wi...>
> > To: <dyn...@li...>
> > Sent: Tuesday, February 20, 2001 12:20 PM
> > Subject: RE: [Dynapi-Dev] Dynamic Loading.
> >
> >
> > >
> > > >I loath the limited realm that FLASH delivers along with its
> > > >pathetic CPU chewing rendering engine.  I like the fact that the
DynAPI
> > > >leaves options 100% open for me to pick and choose front-to-back
> delivery
> > > >platforms.
> > >
> > > I agree, though as it stands, DynAPI chews more CPU time than the
> average
> > > flash
> > > movie, let alone IE memory leaks.
> > >
> > > >Currently loadpanel is probably the weakest link supporting the
DynAPI
> > > >platform.  But it is the "only" link we currently have to bridge
> between
> > > two
> > > >very different worlds.  Fix and optimize it....,
> > >
> > > Hmmm, I think that setHTML is the way to go, not loadpanel.
> > > Using PHP, for instance, you can load a PHP file in a hidden frame,
that
> > > accesses
> > > a database and builds a script on that hidden page that alters the
layer
> > > content
> > > on the main page via setHTML. In practice, if you organize things
> > > thouroughly, you
> > > won't have to reload the main page ever.
> > >
> > > best,
> > >
> > > NunoF
> > >
> > >
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
>
>
> ---
> Outgoing mail is certified Virus Free by AVG Free Edition
> Download at: http://www.grisoft.com/html/us_index.cfm
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

RE: [Dynapi-Dev] Freeing Memory

[.:: O. ::. <oc...@ho...>]

A voice of reason !

There's no flames from this camp.


>From: "Pascal" <pb...@oi...>
>Reply-To: dyn...@li...
>To: <dyn...@li...>
>Subject: RE: [Dynapi-Dev] Freeing Memory
>Date: Wed, 21 Feb 2001 08:54:48 +0100
>
>Well to get this said in time:
>
>I think that any moves towards a DynAPI3 should be on a seperate 
>sourceforge
>project (or atleast other location).
>
>I have absolutely no interest in doing everything all over again or even
>participating in a venture like that.
>
>The DynAPI2 has been in development for little more then a year  now, and 
>we
>"made" everyone drop the dynapi1 in favour of DynAPI2 saying "dynapi1 is
>discontinued, dynapi2 will support ie55 and ns6 and other new browsers, 
>it's
>better more flexible and you should just use it"
>
>Now you guys are thinking about doing it all over again.. this means you'r
>saying to all the users (and there are ALOT)  sorry people, now you'll have
>to use this unfinished-slightly-not-100%-working version of a crossbrowser
>library  because we're going to redo everything.
>
>Most people here haven't been involved with the full developing of the
>DynAPI, I can think of only 3 persons at this moment that have been
>participating in the development for this long period (and still only about
>3-5 persons doing all the stuff: documentation, bug fixing, patches,
>administrating, etc).
>
>In one more year, alot of you will have abonded the API3 completely, 
>leaving
>only a few guys on board.. the API will work crossbrowser partially, and 
>not
>fully supporting the latest browsers (by that time something like versions
>110 of those browsers and DOM20)... Seen it happen already with this code,
>don't want to redo it just to end up with the same thing.
>
>In the beginning we had clean code, it was backwards compatible and was 
>nice
>to look at, but didn't had the powerfull functionality it has now.. There's
>not much wrong with the current API, the only thing is that no body ever
>took the time to go thru the code and optimise it. I for one will keep
>working on THIS version of the API and know it can be cleaned up, and make
>it work on any other future browsers coming our way.
>
>let the flaming begin.
>
>Pascal Bestebroer (pb...@oi...)
>Software ontwikkelaar
>Oberon Informatiesystemen b.v.
>http://www.oibv.com
>
>
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/lists/listinfo/dynapi-dev

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Re: [Dynapi-Dev] Freeing Memory

[Jordi - I. - M. <jmi...@or...>]

Amen. However Pascal I don't think anyone pretends to redo the API. We should
blame Raymond ( as usual :) ) because he introduced the 3 in the name and made
it all look scary.

When we're saying DynAPI3 I understand we're meaning DynAPI2 with better and
cleaner code, not a new API.

Pascal wrote:

> Well to get this said in time:
>
> I think that any moves towards a DynAPI3 should be on a seperate sourceforge
> project (or atleast other location).
>
> I have absolutely no interest in doing everything all over again or even
> participating in a venture like that.
>
> The DynAPI2 has been in development for little more then a year  now, and we
> "made" everyone drop the dynapi1 in favour of DynAPI2 saying "dynapi1 is
> discontinued, dynapi2 will support ie55 and ns6 and other new browsers, it's
> better more flexible and you should just use it"
>
> Now you guys are thinking about doing it all over again.. this means you'r
> saying to all the users (and there are ALOT)  sorry people, now you'll have
> to use this unfinished-slightly-not-100%-working version of a crossbrowser
> library  because we're going to redo everything.
>
> Most people here haven't been involved with the full developing of the
> DynAPI, I can think of only 3 persons at this moment that have been
> participating in the development for this long period (and still only about
> 3-5 persons doing all the stuff: documentation, bug fixing, patches,
> administrating, etc).
>
> In one more year, alot of you will have abonded the API3 completely, leaving
> only a few guys on board.. the API will work crossbrowser partially, and not
> fully supporting the latest browsers (by that time something like versions
> 110 of those browsers and DOM20)... Seen it happen already with this code,
> don't want to redo it just to end up with the same thing.
>
> In the beginning we had clean code, it was backwards compatible and was nice
> to look at, but didn't had the powerfull functionality it has now.. There's
> not much wrong with the current API, the only thing is that no body ever
> took the time to go thru the code and optimise it. I for one will keep
> working on THIS version of the API and know it can be cleaned up, and make
> it work on any other future browsers coming our way.
>
> let the flaming begin.
>
> Pascal Bestebroer (pb...@oi...)
> Software ontwikkelaar
> Oberon Informatiesystemen b.v.
> http://www.oibv.com
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

Re: [Dynapi-Dev] Freeing Memory

[Raymond S. <dst...@or...>]

<emote> pulls out blow torch, flick and ignites a cold blue flame....

First off, I can understand your passion, and if you go all the way back to
the very first "lets stop and think about it first, then act" post you will
see that above alpha-next-generation-anything was finish up DynAPI2.

Secondly, beginning discussions (which you should definitely be involved in)
on the planning stages of the next generation of "this" API is certainly
appropriate at this time.  The format that was presented was one of
brushstroke self-appraisal with an eye towards what we would like the next
evolution of this API to be capable of.

Not one mention of "abandon and run" removing the potential for backward
compatibility.  Which I think should be a serious consideration in this
"planning" stage.

At this stage not a single "anything" has been agreed upon.  There have been
lots of discussions related to super-class this, client-side that.  I only
interceded to try and frame and consolidated these "loose" discussions into
a more productive format based on mutual collaboration.  Hence references to
UML, whiteboards and the need to really think before we type.

But...

Based on your most recent rock-throw I personally would like to see this
discussion focus on one thing.

What we would like to do.

Personally, I am looking to the Pascal's and Rainwater's for leadership
here.  I'm only attempting to contribute my time and energies to help push
the ball along.  I've posted 3 times with queries for "input" and received
little in the form of response.

One thread asked which of 3 distinctly different endpoint objectives we have
for this API.  Attached:

(1) A set of surface enhancing widgets for general layman use.  Menu,
windows, navigation devices.
(2) A series of linkable components (server and/or client) that can manage
and present information dynamically within the library of server-side
widgets(1).
(3) Both.  An API that allows the generalist to enhance their site using the
API that also has hooks developed into it that allows a more serious
implementation embracing the whole information interchange circuit; client
to server-side.  As Robert has pointed out these "hooks" could be developed
to allow the user language implementation  flexibility.

Answer this question will go along way to adding a lot of clarity as to what
next-steps in this Open Source Forum, based on and proposing to extend
DynAPI2.

To be honest I was a little disillusioned with the overall response to what
I was proposing.  And I'm certainly not interested in expending a large
amount of my time for nothing.

So,...

Lets decide.  I think your negative whiplash reaction was a little
premature, but knowing the passions of Pascal I understand it.

<emotes> flips blow torch in the air and extends the hand towards the rest
of you all.

RE: [Dynapi-Dev] Freeing Memory

[Pascal <pb...@oi...>]

Well to get this said in time:

I think that any moves towards a DynAPI3 should be on a seperate sourceforge
project (or atleast other location).

I have absolutely no interest in doing everything all over again or even
participating in a venture like that.

The DynAPI2 has been in development for little more then a year  now, and we
"made" everyone drop the dynapi1 in favour of DynAPI2 saying "dynapi1 is
discontinued, dynapi2 will support ie55 and ns6 and other new browsers, it's
better more flexible and you should just use it"

Now you guys are thinking about doing it all over again.. this means you'r
saying to all the users (and there are ALOT)  sorry people, now you'll have
to use this unfinished-slightly-not-100%-working version of a crossbrowser
library  because we're going to redo everything.

Most people here haven't been involved with the full developing of the
DynAPI, I can think of only 3 persons at this moment that have been
participating in the development for this long period (and still only about
3-5 persons doing all the stuff: documentation, bug fixing, patches,
administrating, etc).

In one more year, alot of you will have abonded the API3 completely, leaving
only a few guys on board.. the API will work crossbrowser partially, and not
fully supporting the latest browsers (by that time something like versions
110 of those browsers and DOM20)... Seen it happen already with this code,
don't want to redo it just to end up with the same thing.

In the beginning we had clean code, it was backwards compatible and was nice
to look at, but didn't had the powerfull functionality it has now.. There's
not much wrong with the current API, the only thing is that no body ever
took the time to go thru the code and optimise it. I for one will keep
working on THIS version of the API and know it can be cleaned up, and make
it work on any other future browsers coming our way.

let the flaming begin.

Pascal Bestebroer (pb...@oi...)
Software ontwikkelaar
Oberon Informatiesystemen b.v.
http://www.oibv.com

Re: [Dynapi-Dev] Dynamic Loading.

[Michael P. <mp...@ph...>]

it is a 1k applet that can be seen in action here: AfroAPI Examples - File
Handling : URL

As I've sid previously, there are still a few glitches in NS.  IE works fine.

It uses and applet to download the content and then uses JS to parse the data
and extract the relevant details and evaluate any JS that is contained.

If you want, I can send you the WIP code.

Nuno Ferreira wrote:

> How does it run?
> Do you call it from Javascript? Or it's a normal Java Applet?
>
> -----Original Message-----
> From: dyn...@li...
> [mailto:dyn...@li...]On Behalf Of Michael
> Pemberton
> Sent: terca-feira, 20 de Fevereiro de 2001 12:52
> To: dyn...@li...
> Subject: Re: [Dynapi-Dev] Dynamic Loading.
>
> this is basically what I have done with my url applet.  it loads the raw
> source and
> then evaluates what needs to be done.  I think it is better than writing a
> lot of
> repetative JS in a separate frame.
>
> Nuno Ferreira wrote:
>
> >         >I loath the limited realm that FLASH delivers along with its
> >         >pathetic CPU chewing rendering engine.  I like the fact that the
> DynAPI
> >         >leaves options 100% open for me to pick and choose front-to-back
> delivery
> >         >platforms.
> >
> > I agree, though as it stands, DynAPI chews more CPU time than the average
> > flash
> > movie, let alone IE memory leaks.
> >
> >         >Currently loadpanel is probably the weakest link supporting the
> DynAPI
> >         >platform.  But it is the "only" link we currently have to bridge
> between
> > two
> >         >very different worlds.  Fix and optimize it....,
> >
> > Hmmm, I think that setHTML is the way to go, not loadpanel.
> > Using PHP, for instance, you can load a PHP file in a hidden frame, that
> > accesses
> > a database and builds a script on that hidden page that alters the layer
> > content
> > on the main page via setHTML. In practice, if you organize things
> > thouroughly, you
> > won't have to reload the main page ever.
> >
> > best,
> >
> > NunoF
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
> --
> Michael Pemberton
> mp...@ph...
> ICQ: 12107010
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

--
Michael Pemberton
mp...@ph...
ICQ: 12107010

Re: [Dynapi-Dev] Freeing Memory

[Doug M. <do...@cr...>]

>I'm 99% sure of this... but this would lead to the question of why they
bothered putting in bit >calculation in the first place...>


That's easy, Javascript was supposed to be as functionally similar to Java
as possible



---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] [Bug #133325] Some properties don't work with netscape 6 or Mozilla

[<ni...@pr...>]

> Details: Well, i think everything is said in the title. U can create layers
> or "easy2do" things, but when u'd like to use a scrollbar or other things
> like that, it doesn't work with netscape 6 or the latest mozilla. Too bad,
> this API is one of the best i've never seen :/

this is new I never heard of problem with ns 6 




ps. just kidding

SV: [Dynapi-Dev] Freeing Memory

[Bart B. <ba...@ho...>]

Yes it would be slower.
Bit shifting is faked in Javascript actually. From what I know you are =
actually working with 32 bit ingegers tha whole time...  so the JS =
interpreter actually has to perform an additional operation to work with =
bits... transforming it back and forth , where needed.
I'm 99% sure of this... but this would lead to the question of why they =
bothered putting in bit calculation in the first place...

-----Ursprungligt meddelande-----
Fr=E5n: Jeff Greenberg <je...@we...>
Till: dyn...@li... =
<dyn...@li...>
Datum: den 20 februari 2001 22:23
=C4mne: Re: [Dynapi-Dev] Freeing Memory


>This kind of thing becomes troublesome in javascript.
>
>For instance, bit shifting for multiples of 2 is great.... except that =
all my
>tests show that it offers no advantages, and, in fact, is sometimes =
slower in
>javascript than just multiplying by 2. (If anyone wants to see a demo =
of this I
>will post it on my site).
>
>Lookup tables fair a little better, but their gain over straight =
calculations
>only seems to be about 3 or 4 percent at most (I need to check this =
more
>thouroughly).
>
>
>
>Jeff Greenberg
>je...@we...
>
>Raymond Smith wrote:
>
>> I'm really beginning to think there are two sides to this issue.
>>
>> 1)  Design Methodology.
>> 2)  Code Optimization.
>>
>> 1) Eytan eluded to this here, "and then nullify them nothing happens =
but
>> when you recreate them still the memory stays stable".  Today most =
sites are
>> page based, and I think within a common site URL browsers attempt to =
"hold
>> history active" till you leave to an all new destination, then purge =
memory.
>>
>> Everything I have been trying to do is based on using the DynAPI to =
create a
>> single interface linked to a dynamically created, updated and =
evolving site.
>> Think of the JS as providing "interface" only.  Then you would use =
dynamic
>> content engines to pump new content into "reusable components" using =
set"xx"
>> methods (heck you could even reskin an object on the fly).  This is =
the
>> direction the web is moving anyway with CSS and XML anyway.
>>
>> There's no reason you couldn't initialize a series of display widgets =
then
>> call them in, resize them and modify content based on user =
activities.  I
>> think page based browsing + DynAPI (with any level of pizzazz) is a =
recipe
>> for failure.  It will eventually overload the system since every page =
is
>> going to want it's own widget set.  Design would be based on creating =
sites
>> with as tight a "widget depth (how many total layers)" as possible.  =
Reuse
>> widgets (if possible) prior to creating new instances of a prototype.
>>
>> 2) Optimization.  I came from a game developer www.angelstudios.com.  =
I was
>> COO and I found the business of "making games" slow and boring.  The =
idea of
>> waiting and working 2 years to see if you have a winner to only see =
the
>> "bounty" get slyly skimmed into the publishers pockets grows old =
fast).
>> Hence, I left the Industry for the fast paced insanity of the web.  =
But game
>> developers are optimization freaks, they have to be.
>>
>> I did a little research (I wasn't a programmer, I made sure they =
didn't eat
>> to many Twinkies during a specified month because at Angel we bought =
all the
>> Twinkies for our employees; kept them coding longer), and just from a
>> "tricks of the trade standpoint" our code could be significantly =
optimized
>> with a skew towards the Pentium processor set.  I'm sure with =
additional
>> research we could learn even more.  Here's what I found so far:
>>
>> a)  API's, in general, are non-optimizied.  DirectX works (as an API)
>> because it was designed to be as "thin" as possible.
>>
>> b)  Use global variables.  Don't use parameters for allot of =
time-critical
>> functions, instead use a global parameter passing area.  Example:
>>
>>     void Plot(init x, init y, init color) {
>>     // plots a pixel on the screen
>>     video_buffer{x +y*MEMORY_PITCH] =3D color;
>>     }
>>
>> optimized
>>
>>     int gx,gy,gz,color;  //define globals
>>
>>     void Plot_G(void) {
>>     video_buffer[gx + gy*MEMORY_PITCH] =3D color;
>>     }
>>
>> I realize we are an API, but implementing aspects of this where =
appropriate
>> will help.
>>
>> 2)  Always use 32-bit variables rather then 8- or 16-bit.  The =
Pentium and
>> later processors are all 32-bit.  This means they don't like 8- or =
16-bit
>> data words, and in fact, smaller data can slow them down due to =
caching and
>> other related memory anomalies.  Example:
>>
>>     struct CPOINT {
>>     short x,y;
>>     unsigned char c;
>>     }
>>
>> Optimized
>>
>>     struct CPOINT {
>>     int x,y;
>>     int c;
>>     }
>>
>> I don't think this applies a great deal to the current API but I am =
sharing
>> it anyway.
>>
>> 3)  Program in a RISC-like (reduced instruction set computer) manner. =
 In
>> other words make code simple rather then complex.  Pentium class =
processors
>> like simple instructions rather then complex ones.  Longer simpler =
code is
>> faster then short complex code structures.  Example:
>>
>>     if ((x+=3D(2*buffer[index++])>10) {
>>     do stuff...
>>     }
>>
>> Optimized
>>
>>     x+=3D(2*buffer[index]);
>>     index++;
>>
>>     if (x>10) {
>>     do stuff...
>>     }
>>
>> We do sin here a bit....
>>
>> 4)  Use binary shifts for simple multiplication of integers by powers =
of 2.
>> Since all data in a computer is stored in a binary form, shifting the =
bit
>> pattern to the left or right is equivalent to multiplication or =
division.
>> Example:
>>
>>     int y_pos =3D 10:
>>     // multiple y_pos by 64
>>     y_pos =3D (y_pos << 6);  //2^6=3D64
>>
>> Similarly,
>>
>>     //to divide y_pos by 8
>>     y_pos =3D (y_pos >> 3); // 1/2^3 =3D 1/8
>>
>> Disadvantage... confusing code to some.
>>
>> 5)  Write efficient algorithms.
>>
>> 6)  Don't write complex data structures for simple objects.
>>
>> 7)  Don't go crazy with inheritance and layers of software.  Keep the =
base
>> as lean as possible.
>>
>> 8)   The Pentium-class processors use an internal data and code =
cache.  Be
>> aware of this, and try to keep the size of your functions relatively =
small
>> so they can fit into the cache (16KB-32KB+).  Store data in an =
accessible
>> way, it minimizes cache thrashing and main memory or secondary cache =
access,
>> which is 10 times slower than the internal cache.
>>
>> 9) Use precomputed "look-up tables" when possible.
>>
>> So, I think that freeing memory and optimizing speed will be the =
marriage of
>> a quality site design/interface and a well constructed code base to =
draw
>> from.  While some users will elect to take a more conventional path I =
think
>> this will ultimately lead the the best "final result".  But hey!  I'm =
just a
>> designer...
>>
>> Ray
>>
>> _______________________________________________
>> Dynapi-Dev mailing list
>> Dyn...@li...
>> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
>
>_______________________________________________
>Dynapi-Dev mailing list
>Dyn...@li...
>http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

[Dynapi-Dev] [Bug #133325] Some properties don't work with netscape 6 or Mozilla

[<no...@so...>]

Bug #133325, was updated on 2001-Feb-20 15:08
Here is a current snapshot of the bug.

Project: DynAPI 2
Category: Browser-Specific Issue
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: Some properties don't work with netscape 6 or Mozilla

Details: Well, i think everything is said in the title. U can create layers
or "easy2do" things, but when u'd like to use a scrollbar or other things
like that, it doesn't work with netscape 6 or the latest mozilla. Too bad,
this API is one of the best i've never seen :/

Follow-Ups:

Date: 2001-Feb-20 15:09
By: nobody

Comment:
it's still me ;) pliz email me at yo...@da... if u found a solution
=))
-------------------------------------------------------

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133325&group_id=5757

[Dynapi-Dev] [Bug #133325] Some properties don't work with netscape 6 or Mozilla

[<no...@so...>]

Bug #133325, was updated on 2001-Feb-20 15:08
Here is a current snapshot of the bug.

Project: DynAPI 2
Category: Browser-Specific Issue
Status: Open
Resolution: None
Bug Group: None
Priority: 5
Submitted by: nobody
Assigned to : nobody
Summary: Some properties don't work with netscape 6 or Mozilla

Details: Well, i think everything is said in the title. U can create layers
or "easy2do" things, but when u'd like to use a scrollbar or other things
like that, it doesn't work with netscape 6 or the latest mozilla. Too bad,
this API is one of the best i've never seen :/

For detailed info, follow this link:
http://sourceforge.net/bugs/?func=detailbug&bug_id=133325&group_id=5757

RE: [Dynapi-Dev] delete command

[Bradford M. <BM...@ca...>]

he delete command has been around since js1.2, 8an
see ref >>>
http://developer.netscape.com/docs/manuals/js/core/jsref15/ops.html#1045=
837
<http://developer.netscape.com/docs/manuals/js/core/jsref15/ops.html#104=
5837
>=20

  - =DF=AE=AA=D0
=20
p.s. if i've learned anything from mail-lists, then it would have to be =
not
to unclude the previous message when replying, either=20
that or ONLY including the specific message i'm replying to. other wise =
the
recievers of the the mail-list get really really long=20
email messages that mostly don't mean much because they already have =
the
refered to emails, plus they don't really want to see=20
a string of :
_______________________________________________
        Dynapi-Dev mailing list
        Dyn...@li...
<mailto:Dyn...@li...>=20
        http://lists.sourceforge.net/lists/listinfo/dynapi-dev
<http://lists.sourceforge.net/lists/listinfo/dynapi-dev>=20
=20
over and over again. the www.mail-archive.com =
<http://www.mail-archive.com>
crew is lucky because the site filters all that yuckiness out, but us =
others
arn't so fortunate.

Re: [Dynapi-Dev] Freeing Memory

[Doug M. <do...@cr...>]

Which is what I ment..
:-)

----- Original Message -----
From: "Raymond Smith" <dst...@or...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 2:21 PM
Subject: Re: [Dynapi-Dev] Freeing Memory


> That or what Robert eluded to.  Someway of remote notation of a single
> central document.
>
> ----- Original Message -----
> From: "Doug Melvin" <do...@cr...>
> To: <dyn...@li...>
> Sent: Tuesday, February 20, 2001 5:14 PM
> Subject: Re: [Dynapi-Dev] Freeing Memory
>
>
> > How about a multi-user collaborative 'whiteboard' app?
> >
> > If I see enough interest I could build one fairly quikly..
> >
> >
> > ----- Original Message -----
> > From: "Raymond Smith" <dst...@or...>
> > To: <dyn...@li...>
> > Sent: Tuesday, February 20, 2001 2:10 PM
> > Subject: Re: [Dynapi-Dev] Freeing Memory
> >
> >
> > > The three strongest "thread" categories have been:
> > >
> > > 1) Speed optimization
> > > 2) Dynamic content
> > > 3) API overall construction method
> > >
> > > NOTE:  I left DynBuilder out because I think that is a sister
initiative
> > > that wraps around whatever we elect to make the DynAPI do.
> > >
> > > I really think all three of these are parts of a single "new" whole we
> > > should be targeting for the DynAPI3.  One eludes to and dictates
> > > requirements for the others.  Any way, this is a bit premature since I
> am
> > > still trying to get this stack of paper into a single presentable
form.
> > >
> > > But the first fundamental question we need to ask ourselves about the
> next
> > > generation of this API is, "What we intend it to be used for."
> > >
> > > (1) A set of surface enhancing widgets for general layman use.  Menu,
> > > windows, navigation devices.
> > > (2) A series of linkable components (server and/or client) that can
> manage
> > > and present information dynamically within the library of server-side
> > > widgets(1).
> > > (3) Both.  An API that allows the generalist to enhance their site
using
> > the
> > > API that also has hooks developed into it that allows a more serious
> > > implementation embracing the whole information interchange circuit;
> client
> > > to server-side.  As Robert has pointed out these "hooks" could be
> > developed
> > > to allow the user language implementation  flexibility.
> > >
> > > Answer this question, and it will go along ways to defining what we do
> and
> > > focus on next.
> > >
> > > Ray
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "Eytan Heidingsfeld" <ey...@tr...>
> > > To: <dyn...@li...>
> > > Sent: Tuesday, February 20, 2001 1:36 PM
> > > Subject: RE: [Dynapi-Dev] Freeing Memory
> > >
> > >
> > > > All those tips are great for optimizing performance in compiled code
> > > running
> > > > on Pentium machines. Small problem we here are interpreted code. All
> > code
> > > is
> > > > evaluated at run time. Anyway that kind of optimization is to try
and
> > snip
> > > > off milliseconds. Here we are talking about seconds going to waste
not
> 1
> > > > millisecond faster or slower.
> > > >
> > > > About the other idea of using one set of objects and updating. I
like
> it
> > > > BUT:
> > > > * We need some sort of fail-proof content delivery mechanism.
> > > > * If you want this then you definitely need to restructure the API
to
> > > > provide an Application like interface with mem manegment.
> > > >
> > > > 8an
> > > >
> > > >
> > > > _______________________________________________
> > > > Dynapi-Dev mailing list
> > > > Dyn...@li...
> > > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> > > >
> > >
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
> >
> > ---
> > Outgoing mail is certified Virus Free by AVG Free Edition
> > Download at: http://www.grisoft.com/html/us_index.cfm
> > Checked by AVG anti-virus system (http://www.grisoft.com).
> > Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] Freeing Memory

[Raymond S. <dst...@or...>]

That or what Robert eluded to.  Someway of remote notation of a single
central document.

----- Original Message -----
From: "Doug Melvin" <do...@cr...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 5:14 PM
Subject: Re: [Dynapi-Dev] Freeing Memory


> How about a multi-user collaborative 'whiteboard' app?
>
> If I see enough interest I could build one fairly quikly..
>
>
> ----- Original Message -----
> From: "Raymond Smith" <dst...@or...>
> To: <dyn...@li...>
> Sent: Tuesday, February 20, 2001 2:10 PM
> Subject: Re: [Dynapi-Dev] Freeing Memory
>
>
> > The three strongest "thread" categories have been:
> >
> > 1) Speed optimization
> > 2) Dynamic content
> > 3) API overall construction method
> >
> > NOTE:  I left DynBuilder out because I think that is a sister initiative
> > that wraps around whatever we elect to make the DynAPI do.
> >
> > I really think all three of these are parts of a single "new" whole we
> > should be targeting for the DynAPI3.  One eludes to and dictates
> > requirements for the others.  Any way, this is a bit premature since I
am
> > still trying to get this stack of paper into a single presentable form.
> >
> > But the first fundamental question we need to ask ourselves about the
next
> > generation of this API is, "What we intend it to be used for."
> >
> > (1) A set of surface enhancing widgets for general layman use.  Menu,
> > windows, navigation devices.
> > (2) A series of linkable components (server and/or client) that can
manage
> > and present information dynamically within the library of server-side
> > widgets(1).
> > (3) Both.  An API that allows the generalist to enhance their site using
> the
> > API that also has hooks developed into it that allows a more serious
> > implementation embracing the whole information interchange circuit;
client
> > to server-side.  As Robert has pointed out these "hooks" could be
> developed
> > to allow the user language implementation  flexibility.
> >
> > Answer this question, and it will go along ways to defining what we do
and
> > focus on next.
> >
> > Ray
> >
> >
> >
> > ----- Original Message -----
> > From: "Eytan Heidingsfeld" <ey...@tr...>
> > To: <dyn...@li...>
> > Sent: Tuesday, February 20, 2001 1:36 PM
> > Subject: RE: [Dynapi-Dev] Freeing Memory
> >
> >
> > > All those tips are great for optimizing performance in compiled code
> > running
> > > on Pentium machines. Small problem we here are interpreted code. All
> code
> > is
> > > evaluated at run time. Anyway that kind of optimization is to try and
> snip
> > > off milliseconds. Here we are talking about seconds going to waste not
1
> > > millisecond faster or slower.
> > >
> > > About the other idea of using one set of objects and updating. I like
it
> > > BUT:
> > > * We need some sort of fail-proof content delivery mechanism.
> > > * If you want this then you definitely need to restructure the API to
> > > provide an Application like interface with mem manegment.
> > >
> > > 8an
> > >
> > >
> > > _______________________________________________
> > > Dynapi-Dev mailing list
> > > Dyn...@li...
> > > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> > >
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>
>
> ---
> Outgoing mail is certified Virus Free by AVG Free Edition
> Download at: http://www.grisoft.com/html/us_index.cfm
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] Freeing Memory

[Doug M. <do...@cr...>]

How about a multi-user collaborative 'whiteboard' app?

If I see enough interest I could build one fairly quikly..


----- Original Message -----
From: "Raymond Smith" <dst...@or...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 2:10 PM
Subject: Re: [Dynapi-Dev] Freeing Memory


> The three strongest "thread" categories have been:
>
> 1) Speed optimization
> 2) Dynamic content
> 3) API overall construction method
>
> NOTE:  I left DynBuilder out because I think that is a sister initiative
> that wraps around whatever we elect to make the DynAPI do.
>
> I really think all three of these are parts of a single "new" whole we
> should be targeting for the DynAPI3.  One eludes to and dictates
> requirements for the others.  Any way, this is a bit premature since I am
> still trying to get this stack of paper into a single presentable form.
>
> But the first fundamental question we need to ask ourselves about the next
> generation of this API is, "What we intend it to be used for."
>
> (1) A set of surface enhancing widgets for general layman use.  Menu,
> windows, navigation devices.
> (2) A series of linkable components (server and/or client) that can manage
> and present information dynamically within the library of server-side
> widgets(1).
> (3) Both.  An API that allows the generalist to enhance their site using
the
> API that also has hooks developed into it that allows a more serious
> implementation embracing the whole information interchange circuit; client
> to server-side.  As Robert has pointed out these "hooks" could be
developed
> to allow the user language implementation  flexibility.
>
> Answer this question, and it will go along ways to defining what we do and
> focus on next.
>
> Ray
>
>
>
> ----- Original Message -----
> From: "Eytan Heidingsfeld" <ey...@tr...>
> To: <dyn...@li...>
> Sent: Tuesday, February 20, 2001 1:36 PM
> Subject: RE: [Dynapi-Dev] Freeing Memory
>
>
> > All those tips are great for optimizing performance in compiled code
> running
> > on Pentium machines. Small problem we here are interpreted code. All
code
> is
> > evaluated at run time. Anyway that kind of optimization is to try and
snip
> > off milliseconds. Here we are talking about seconds going to waste not 1
> > millisecond faster or slower.
> >
> > About the other idea of using one set of objects and updating. I like it
> > BUT:
> > * We need some sort of fail-proof content delivery mechanism.
> > * If you want this then you definitely need to restructure the API to
> > provide an Application like interface with mem manegment.
> >
> > 8an
> >
> >
> > _______________________________________________
> > Dynapi-Dev mailing list
> > Dyn...@li...
> > http://lists.sourceforge.net/lists/listinfo/dynapi-dev
> >
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] Freeing Memory

[Raymond S. <dst...@or...>]

The three strongest "thread" categories have been:

1) Speed optimization
2) Dynamic content
3) API overall construction method

NOTE:  I left DynBuilder out because I think that is a sister initiative
that wraps around whatever we elect to make the DynAPI do.

I really think all three of these are parts of a single "new" whole we
should be targeting for the DynAPI3.  One eludes to and dictates
requirements for the others.  Any way, this is a bit premature since I am
still trying to get this stack of paper into a single presentable form.

But the first fundamental question we need to ask ourselves about the next
generation of this API is, "What we intend it to be used for."

(1) A set of surface enhancing widgets for general layman use.  Menu,
windows, navigation devices.
(2) A series of linkable components (server and/or client) that can manage
and present information dynamically within the library of server-side
widgets(1).
(3) Both.  An API that allows the generalist to enhance their site using the
API that also has hooks developed into it that allows a more serious
implementation embracing the whole information interchange circuit; client
to server-side.  As Robert has pointed out these "hooks" could be developed
to allow the user language implementation  flexibility.

Answer this question, and it will go along ways to defining what we do and
focus on next.

Ray



----- Original Message -----
From: "Eytan Heidingsfeld" <ey...@tr...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 1:36 PM
Subject: RE: [Dynapi-Dev] Freeing Memory


> All those tips are great for optimizing performance in compiled code
running
> on Pentium machines. Small problem we here are interpreted code. All code
is
> evaluated at run time. Anyway that kind of optimization is to try and snip
> off milliseconds. Here we are talking about seconds going to waste not 1
> millisecond faster or slower.
>
> About the other idea of using one set of objects and updating. I like it
> BUT:
> * We need some sort of fail-proof content delivery mechanism.
> * If you want this then you definitely need to restructure the API to
> provide an Application like interface with mem manegment.
>
> 8an
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

RE: [Dynapi-Dev] Freeing Memory

[Eytan H. <ey...@tr...>]

All those tips are great for optimizing performance in compiled code running
on Pentium machines. Small problem we here are interpreted code. All code is
evaluated at run time. Anyway that kind of optimization is to try and snip
off milliseconds. Here we are talking about seconds going to waste not 1
millisecond faster or slower.

About the other idea of using one set of objects and updating. I like it
BUT:
* We need some sort of fail-proof content delivery mechanism.
* If you want this then you definitely need to restructure the API to
provide an Application like interface with mem manegment.

8an

Re: [Dynapi-Dev] Freeing Memory

[Jeff G. <je...@we...>]

This kind of thing becomes troublesome in javascript.

For instance, bit shifting for multiples of 2 is great.... except that all my
tests show that it offers no advantages, and, in fact, is sometimes slower in
javascript than just multiplying by 2. (If anyone wants to see a demo of this I
will post it on my site).

Lookup tables fair a little better, but their gain over straight calculations
only seems to be about 3 or 4 percent at most (I need to check this more
thouroughly).



Jeff Greenberg
je...@we...

Raymond Smith wrote:

> I'm really beginning to think there are two sides to this issue.
>
> 1)  Design Methodology.
> 2)  Code Optimization.
>
> 1) Eytan eluded to this here, "and then nullify them nothing happens but
> when you recreate them still the memory stays stable".  Today most sites are
> page based, and I think within a common site URL browsers attempt to "hold
> history active" till you leave to an all new destination, then purge memory.
>
> Everything I have been trying to do is based on using the DynAPI to create a
> single interface linked to a dynamically created, updated and evolving site.
> Think of the JS as providing "interface" only.  Then you would use dynamic
> content engines to pump new content into "reusable components" using set"xx"
> methods (heck you could even reskin an object on the fly).  This is the
> direction the web is moving anyway with CSS and XML anyway.
>
> There's no reason you couldn't initialize a series of display widgets then
> call them in, resize them and modify content based on user activities.  I
> think page based browsing + DynAPI (with any level of pizzazz) is a recipe
> for failure.  It will eventually overload the system since every page is
> going to want it's own widget set.  Design would be based on creating sites
> with as tight a "widget depth (how many total layers)" as possible.  Reuse
> widgets (if possible) prior to creating new instances of a prototype.
>
> 2) Optimization.  I came from a game developer www.angelstudios.com.  I was
> COO and I found the business of "making games" slow and boring.  The idea of
> waiting and working 2 years to see if you have a winner to only see the
> "bounty" get slyly skimmed into the publishers pockets grows old fast).
> Hence, I left the Industry for the fast paced insanity of the web.  But game
> developers are optimization freaks, they have to be.
>
> I did a little research (I wasn't a programmer, I made sure they didn't eat
> to many Twinkies during a specified month because at Angel we bought all the
> Twinkies for our employees; kept them coding longer), and just from a
> "tricks of the trade standpoint" our code could be significantly optimized
> with a skew towards the Pentium processor set.  I'm sure with additional
> research we could learn even more.  Here's what I found so far:
>
> a)  API's, in general, are non-optimizied.  DirectX works (as an API)
> because it was designed to be as "thin" as possible.
>
> b)  Use global variables.  Don't use parameters for allot of time-critical
> functions, instead use a global parameter passing area.  Example:
>
>     void Plot(init x, init y, init color) {
>     // plots a pixel on the screen
>     video_buffer{x +y*MEMORY_PITCH] = color;
>     }
>
> optimized
>
>     int gx,gy,gz,color;  //define globals
>
>     void Plot_G(void) {
>     video_buffer[gx + gy*MEMORY_PITCH] = color;
>     }
>
> I realize we are an API, but implementing aspects of this where appropriate
> will help.
>
> 2)  Always use 32-bit variables rather then 8- or 16-bit.  The Pentium and
> later processors are all 32-bit.  This means they don't like 8- or 16-bit
> data words, and in fact, smaller data can slow them down due to caching and
> other related memory anomalies.  Example:
>
>     struct CPOINT {
>     short x,y;
>     unsigned char c;
>     }
>
> Optimized
>
>     struct CPOINT {
>     int x,y;
>     int c;
>     }
>
> I don't think this applies a great deal to the current API but I am sharing
> it anyway.
>
> 3)  Program in a RISC-like (reduced instruction set computer) manner.  In
> other words make code simple rather then complex.  Pentium class processors
> like simple instructions rather then complex ones.  Longer simpler code is
> faster then short complex code structures.  Example:
>
>     if ((x+=(2*buffer[index++])>10) {
>     do stuff...
>     }
>
> Optimized
>
>     x+=(2*buffer[index]);
>     index++;
>
>     if (x>10) {
>     do stuff...
>     }
>
> We do sin here a bit....
>
> 4)  Use binary shifts for simple multiplication of integers by powers of 2.
> Since all data in a computer is stored in a binary form, shifting the bit
> pattern to the left or right is equivalent to multiplication or division.
> Example:
>
>     int y_pos = 10:
>     // multiple y_pos by 64
>     y_pos = (y_pos << 6);  //2^6=64
>
> Similarly,
>
>     //to divide y_pos by 8
>     y_pos = (y_pos >> 3); // 1/2^3 = 1/8
>
> Disadvantage... confusing code to some.
>
> 5)  Write efficient algorithms.
>
> 6)  Don't write complex data structures for simple objects.
>
> 7)  Don't go crazy with inheritance and layers of software.  Keep the base
> as lean as possible.
>
> 8)   The Pentium-class processors use an internal data and code cache.  Be
> aware of this, and try to keep the size of your functions relatively small
> so they can fit into the cache (16KB-32KB+).  Store data in an accessible
> way, it minimizes cache thrashing and main memory or secondary cache access,
> which is 10 times slower than the internal cache.
>
> 9) Use precomputed "look-up tables" when possible.
>
> So, I think that freeing memory and optimizing speed will be the marriage of
> a quality site design/interface and a well constructed code base to draw
> from.  While some users will elect to take a more conventional path I think
> this will ultimately lead the the best "final result".  But hey!  I'm just a
> designer...
>
> Ray
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev

Re: [Dynapi-Dev] Freeing Memory

[Raymond S. <dst...@or...>]

I was gonna say that, but I knew you would and my thread was to long
already...

;O)

From: "Pascal Bestebroer" <pa...@dy...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 1:11 PM
Subject: RE: [Dynapi-Dev] Freeing Memory


> ke.. some thoughts.
>
> Javascript is interpreted.. so all of your Pentium /cpu ops.  might not be
> of any concern.
> We need to make sure the JS parser handles it the quickest.. this could
pose
> another set of rules then your cpu rules.
>
> Sadly we have no clue on how the JS parsers work, and what they like more,
> so we should try these things first before using the compiled language
like
> optimisations.
>
>
>
> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net

RE: [Dynapi-Dev] Freeing Memory

[Pascal B. <pa...@dy...>]

ke.. some thoughts.

Javascript is interpreted.. so all of your Pentium /cpu ops.  might not be
of any concern.
We need to make sure the JS parser handles it the quickest.. this could pose
another set of rules then your cpu rules.

Sadly we have no clue on how the JS parsers work, and what they like more,
so we should try these things first before using the compiled language like
optimisations.



Pascal Bestebroer
pa...@dy...
http://www.dynamic-core.net

> -----Oorspronkelijk bericht-----
> Van: dyn...@li...
> [mailto:dyn...@li...]Namens Raymond Smith
> Verzonden: dinsdag 20 februari 2001 21:51
> Aan: dyn...@li...
> Onderwerp: Re: [Dynapi-Dev] Freeing Memory
>
>
> I'm really beginning to think there are two sides to this issue.
>
> 1)  Design Methodology.
> 2)  Code Optimization.
>
> 1) Eytan eluded to this here, "and then nullify them nothing happens but
> when you recreate them still the memory stays stable".  Today
> most sites are
> page based, and I think within a common site URL browsers attempt to "hold
> history active" till you leave to an all new destination, then
> purge memory.
>
> Everything I have been trying to do is based on using the DynAPI
> to create a
> single interface linked to a dynamically created, updated and
> evolving site.
> Think of the JS as providing "interface" only.  Then you would use dynamic
> content engines to pump new content into "reusable components"
> using set"xx"
> methods (heck you could even reskin an object on the fly).  This is the
> direction the web is moving anyway with CSS and XML anyway.
>
> There's no reason you couldn't initialize a series of display widgets then
> call them in, resize them and modify content based on user activities.  I
> think page based browsing + DynAPI (with any level of pizzazz) is a recipe
> for failure.  It will eventually overload the system since every page is
> going to want it's own widget set.  Design would be based on
> creating sites
> with as tight a "widget depth (how many total layers)" as possible.  Reuse
> widgets (if possible) prior to creating new instances of a prototype.
>
> 2) Optimization.  I came from a game developer
> www.angelstudios.com.  I was
> COO and I found the business of "making games" slow and boring.
> The idea of
> waiting and working 2 years to see if you have a winner to only see the
> "bounty" get slyly skimmed into the publishers pockets grows old fast).
> Hence, I left the Industry for the fast paced insanity of the
> web.  But game
> developers are optimization freaks, they have to be.
>
> I did a little research (I wasn't a programmer, I made sure they
> didn't eat
> to many Twinkies during a specified month because at Angel we
> bought all the
> Twinkies for our employees; kept them coding longer), and just from a
> "tricks of the trade standpoint" our code could be significantly optimized
> with a skew towards the Pentium processor set.  I'm sure with additional
> research we could learn even more.  Here's what I found so far:
>
> a)  API's, in general, are non-optimizied.  DirectX works (as an API)
> because it was designed to be as "thin" as possible.
>
> b)  Use global variables.  Don't use parameters for allot of time-critical
> functions, instead use a global parameter passing area.  Example:
>
>     void Plot(init x, init y, init color) {
>     // plots a pixel on the screen
>     video_buffer{x +y*MEMORY_PITCH] = color;
>     }
>
> optimized
>
>     int gx,gy,gz,color;  //define globals
>
>     void Plot_G(void) {
>     video_buffer[gx + gy*MEMORY_PITCH] = color;
>     }
>
> I realize we are an API, but implementing aspects of this where
> appropriate
> will help.
>
> 2)  Always use 32-bit variables rather then 8- or 16-bit.  The Pentium and
> later processors are all 32-bit.  This means they don't like 8- or 16-bit
> data words, and in fact, smaller data can slow them down due to
> caching and
> other related memory anomalies.  Example:
>
>     struct CPOINT {
>     short x,y;
>     unsigned char c;
>     }
>
> Optimized
>
>     struct CPOINT {
>     int x,y;
>     int c;
>     }
>
> I don't think this applies a great deal to the current API but I
> am sharing
> it anyway.
>
> 3)  Program in a RISC-like (reduced instruction set computer) manner.  In
> other words make code simple rather then complex.  Pentium class
> processors
> like simple instructions rather then complex ones.  Longer simpler code is
> faster then short complex code structures.  Example:
>
>     if ((x+=(2*buffer[index++])>10) {
>     do stuff...
>     }
>
> Optimized
>
>     x+=(2*buffer[index]);
>     index++;
>
>     if (x>10) {
>     do stuff...
>     }
>
> We do sin here a bit....
>
> 4)  Use binary shifts for simple multiplication of integers by
> powers of 2.
> Since all data in a computer is stored in a binary form, shifting the bit
> pattern to the left or right is equivalent to multiplication or division.
> Example:
>
>     int y_pos = 10:
>     // multiple y_pos by 64
>     y_pos = (y_pos << 6);  //2^6=64
>
> Similarly,
>
>     //to divide y_pos by 8
>     y_pos = (y_pos >> 3); // 1/2^3 = 1/8
>
> Disadvantage... confusing code to some.
>
> 5)  Write efficient algorithms.
>
> 6)  Don't write complex data structures for simple objects.
>
> 7)  Don't go crazy with inheritance and layers of software.  Keep the base
> as lean as possible.
>
> 8)   The Pentium-class processors use an internal data and code cache.  Be
> aware of this, and try to keep the size of your functions relatively small
> so they can fit into the cache (16KB-32KB+).  Store data in an accessible
> way, it minimizes cache thrashing and main memory or secondary
> cache access,
> which is 10 times slower than the internal cache.
>
> 9) Use precomputed "look-up tables" when possible.
>
>
> So, I think that freeing memory and optimizing speed will be the
> marriage of
> a quality site design/interface and a well constructed code base to draw
> from.  While some users will elect to take a more conventional
> path I think
> this will ultimately lead the the best "final result".  But hey!
> I'm just a
> designer...
>
> Ray
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>

Re: [Dynapi-Dev] Freeing Memory

[Doug M. <do...@cr...>]

Another tip is not to over do it with the 'snazz'.
The problem with my orgigional Demo site was that I used DynAPI wherever
possible.
I have found that one can use simple HTML or plain javascript
in a lot of places (such as for roll-over menus, or 'dynamic' content).
Which in turn speeds up the site and resduces the mem-footprint.

Doug
----- Original Message -----
From: "Raymond Smith" <dst...@or...>
To: <dyn...@li...>
Sent: Tuesday, February 20, 2001 12:51 PM
Subject: Re: [Dynapi-Dev] Freeing Memory


> I'm really beginning to think there are two sides to this issue.
>
> 1)  Design Methodology.
> 2)  Code Optimization.
>
> 1) Eytan eluded to this here, "and then nullify them nothing happens but
> when you recreate them still the memory stays stable".  Today most sites
are
> page based, and I think within a common site URL browsers attempt to "hold
> history active" till you leave to an all new destination, then purge
memory.
>
> Everything I have been trying to do is based on using the DynAPI to create
a
> single interface linked to a dynamically created, updated and evolving
site.
> Think of the JS as providing "interface" only.  Then you would use dynamic
> content engines to pump new content into "reusable components" using
set"xx"
> methods (heck you could even reskin an object on the fly).  This is the
> direction the web is moving anyway with CSS and XML anyway.
>
> There's no reason you couldn't initialize a series of display widgets then
> call them in, resize them and modify content based on user activities.  I
> think page based browsing + DynAPI (with any level of pizzazz) is a recipe
> for failure.  It will eventually overload the system since every page is
> going to want it's own widget set.  Design would be based on creating
sites
> with as tight a "widget depth (how many total layers)" as possible.  Reuse
> widgets (if possible) prior to creating new instances of a prototype.
>
> 2) Optimization.  I came from a game developer www.angelstudios.com.  I
was
> COO and I found the business of "making games" slow and boring.  The idea
of
> waiting and working 2 years to see if you have a winner to only see the
> "bounty" get slyly skimmed into the publishers pockets grows old fast).
> Hence, I left the Industry for the fast paced insanity of the web.  But
game
> developers are optimization freaks, they have to be.
>
> I did a little research (I wasn't a programmer, I made sure they didn't
eat
> to many Twinkies during a specified month because at Angel we bought all
the
> Twinkies for our employees; kept them coding longer), and just from a
> "tricks of the trade standpoint" our code could be significantly optimized
> with a skew towards the Pentium processor set.  I'm sure with additional
> research we could learn even more.  Here's what I found so far:
>
> a)  API's, in general, are non-optimizied.  DirectX works (as an API)
> because it was designed to be as "thin" as possible.
>
> b)  Use global variables.  Don't use parameters for allot of time-critical
> functions, instead use a global parameter passing area.  Example:
>
>     void Plot(init x, init y, init color) {
>     // plots a pixel on the screen
>     video_buffer{x +y*MEMORY_PITCH] = color;
>     }
>
> optimized
>
>     int gx,gy,gz,color;  //define globals
>
>     void Plot_G(void) {
>     video_buffer[gx + gy*MEMORY_PITCH] = color;
>     }
>
> I realize we are an API, but implementing aspects of this where
appropriate
> will help.
>
> 2)  Always use 32-bit variables rather then 8- or 16-bit.  The Pentium and
> later processors are all 32-bit.  This means they don't like 8- or 16-bit
> data words, and in fact, smaller data can slow them down due to caching
and
> other related memory anomalies.  Example:
>
>     struct CPOINT {
>     short x,y;
>     unsigned char c;
>     }
>
> Optimized
>
>     struct CPOINT {
>     int x,y;
>     int c;
>     }
>
> I don't think this applies a great deal to the current API but I am
sharing
> it anyway.
>
> 3)  Program in a RISC-like (reduced instruction set computer) manner.  In
> other words make code simple rather then complex.  Pentium class
processors
> like simple instructions rather then complex ones.  Longer simpler code is
> faster then short complex code structures.  Example:
>
>     if ((x+=(2*buffer[index++])>10) {
>     do stuff...
>     }
>
> Optimized
>
>     x+=(2*buffer[index]);
>     index++;
>
>     if (x>10) {
>     do stuff...
>     }
>
> We do sin here a bit....
>
> 4)  Use binary shifts for simple multiplication of integers by powers of
2.
> Since all data in a computer is stored in a binary form, shifting the bit
> pattern to the left or right is equivalent to multiplication or division.
> Example:
>
>     int y_pos = 10:
>     // multiple y_pos by 64
>     y_pos = (y_pos << 6);  //2^6=64
>
> Similarly,
>
>     //to divide y_pos by 8
>     y_pos = (y_pos >> 3); // 1/2^3 = 1/8
>
> Disadvantage... confusing code to some.
>
> 5)  Write efficient algorithms.
>
> 6)  Don't write complex data structures for simple objects.
>
> 7)  Don't go crazy with inheritance and layers of software.  Keep the base
> as lean as possible.
>
> 8)   The Pentium-class processors use an internal data and code cache.  Be
> aware of this, and try to keep the size of your functions relatively small
> so they can fit into the cache (16KB-32KB+).  Store data in an accessible
> way, it minimizes cache thrashing and main memory or secondary cache
access,
> which is 10 times slower than the internal cache.
>
> 9) Use precomputed "look-up tables" when possible.
>
>
> So, I think that freeing memory and optimizing speed will be the marriage
of
> a quality site design/interface and a well constructed code base to draw
> from.  While some users will elect to take a more conventional path I
think
> this will ultimately lead the the best "final result".  But hey!  I'm just
a
> designer...
>
> Ray
>
>
> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev


---
Outgoing mail is certified Virus Free by AVG Free Edition
Download at: http://www.grisoft.com/html/us_index.cfm
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.231 / Virus Database: 112 - Release Date: 2/12/01

Re: [Dynapi-Dev] Freeing Memory

[Raymond S. <dst...@or...>]

I'm really beginning to think there are two sides to this issue.

1)  Design Methodology.
2)  Code Optimization.

1) Eytan eluded to this here, "and then nullify them nothing happens but
when you recreate them still the memory stays stable".  Today most sites are
page based, and I think within a common site URL browsers attempt to "hold
history active" till you leave to an all new destination, then purge memory.

Everything I have been trying to do is based on using the DynAPI to create a
single interface linked to a dynamically created, updated and evolving site.
Think of the JS as providing "interface" only.  Then you would use dynamic
content engines to pump new content into "reusable components" using set"xx"
methods (heck you could even reskin an object on the fly).  This is the
direction the web is moving anyway with CSS and XML anyway.

There's no reason you couldn't initialize a series of display widgets then
call them in, resize them and modify content based on user activities.  I
think page based browsing + DynAPI (with any level of pizzazz) is a recipe
for failure.  It will eventually overload the system since every page is
going to want it's own widget set.  Design would be based on creating sites
with as tight a "widget depth (how many total layers)" as possible.  Reuse
widgets (if possible) prior to creating new instances of a prototype.

2) Optimization.  I came from a game developer www.angelstudios.com.  I was
COO and I found the business of "making games" slow and boring.  The idea of
waiting and working 2 years to see if you have a winner to only see the
"bounty" get slyly skimmed into the publishers pockets grows old fast).
Hence, I left the Industry for the fast paced insanity of the web.  But game
developers are optimization freaks, they have to be.

I did a little research (I wasn't a programmer, I made sure they didn't eat
to many Twinkies during a specified month because at Angel we bought all the
Twinkies for our employees; kept them coding longer), and just from a
"tricks of the trade standpoint" our code could be significantly optimized
with a skew towards the Pentium processor set.  I'm sure with additional
research we could learn even more.  Here's what I found so far:

a)  API's, in general, are non-optimizied.  DirectX works (as an API)
because it was designed to be as "thin" as possible.

b)  Use global variables.  Don't use parameters for allot of time-critical
functions, instead use a global parameter passing area.  Example:

    void Plot(init x, init y, init color) {
    // plots a pixel on the screen
    video_buffer{x +y*MEMORY_PITCH] = color;
    }

optimized

    int gx,gy,gz,color;  //define globals

    void Plot_G(void) {
    video_buffer[gx + gy*MEMORY_PITCH] = color;
    }

I realize we are an API, but implementing aspects of this where appropriate
will help.

2)  Always use 32-bit variables rather then 8- or 16-bit.  The Pentium and
later processors are all 32-bit.  This means they don't like 8- or 16-bit
data words, and in fact, smaller data can slow them down due to caching and
other related memory anomalies.  Example:

    struct CPOINT {
    short x,y;
    unsigned char c;
    }

Optimized

    struct CPOINT {
    int x,y;
    int c;
    }

I don't think this applies a great deal to the current API but I am sharing
it anyway.

3)  Program in a RISC-like (reduced instruction set computer) manner.  In
other words make code simple rather then complex.  Pentium class processors
like simple instructions rather then complex ones.  Longer simpler code is
faster then short complex code structures.  Example:

    if ((x+=(2*buffer[index++])>10) {
    do stuff...
    }

Optimized

    x+=(2*buffer[index]);
    index++;

    if (x>10) {
    do stuff...
    }

We do sin here a bit....

4)  Use binary shifts for simple multiplication of integers by powers of 2.
Since all data in a computer is stored in a binary form, shifting the bit
pattern to the left or right is equivalent to multiplication or division.
Example:

    int y_pos = 10:
    // multiple y_pos by 64
    y_pos = (y_pos << 6);  //2^6=64

Similarly,

    //to divide y_pos by 8
    y_pos = (y_pos >> 3); // 1/2^3 = 1/8

Disadvantage... confusing code to some.

5)  Write efficient algorithms.

6)  Don't write complex data structures for simple objects.

7)  Don't go crazy with inheritance and layers of software.  Keep the base
as lean as possible.

8)   The Pentium-class processors use an internal data and code cache.  Be
aware of this, and try to keep the size of your functions relatively small
so they can fit into the cache (16KB-32KB+).  Store data in an accessible
way, it minimizes cache thrashing and main memory or secondary cache access,
which is 10 times slower than the internal cache.

9) Use precomputed "look-up tables" when possible.


So, I think that freeing memory and optimizing speed will be the marriage of
a quality site design/interface and a well constructed code base to draw
from.  While some users will elect to take a more conventional path I think
this will ultimately lead the the best "final result".  But hey!  I'm just a
designer...

Ray

Re[2]: [Dynapi-Dev] Freeing Memory

[Robert R. <rra...@ya...>]

You could possibly load the same url with a unique paramater passed in the
url.  I have yet to try this though.

-- 
// Robert Rainwater

On 2/20/2001, 2:27:22 PM EST, Pascal wrote about "[Dynapi-Dev] Freeing Memory":

> so on a url change everything is freed?

> couldn't we then check for a on window close or window blur event? (not sure
> if these are available).. in that case we could do a fast url change or
> something (again, not sure if that's possible)

> Pascal Bestebroer
> pa...@dy...
> http://www.dynamic-core.net

>> -----Oorspronkelijk bericht-----
>> Van: dyn...@li...
>> [mailto:dyn...@li...]Namens Eytan Heidingsfeld
>> Verzonden: dinsdag 20 februari 2001 20:18
>> Aan: Dynapi-Dev
>> Onderwerp: [Dynapi-Dev] Freeing Memory
>>
>>
>> Since IE is way more popular I started with it. I was wrong with my
>> assumption that nullifying objects (not even talking about html
>> elements(layers)) does the whole thing. Let me tell you what I discovered:
>> if you create 10000 small object and then nullify them nothing happens but
>> when you recreate them still the memory stays stable. I want to
>> test replace
>> "= null" with "= [];" maybe that will help.
>> Identified positive freeing of memory when changing url. Now you all may
>> say: "so what this sux we can't force them to change url!!" it might be ok
>> if we design such a system(this design fits well with the talks
>> about a new
>> API"
>> We create a framed page
>> one called RAM and one regular one where you place your project.
>> In the RAM page there is a method called createObject which does the
>> following:
>> * takes the type of object expected
>> * adds a new object of that type to an array called mem
>> * returns the index
>> then on the regular page we say
>> i = createObject(DynLayer);
>> myDynLayer = parent.frames[0].mem[i];
>> (there will be a shortcut to parent.frames[0]).
>>
>> Then when we want to free mem we pass the mem array to the main
>> frame change
>> the url to an empty page and reassign the mem array.
>>
>> Not even sure if this system works. Gonna try it now anyone else
>> got ideas?
>>
>> 8an
>>
>>
>> _______________________________________________
>> Dynapi-Dev mailing list
>> Dyn...@li...
>> http://lists.sourceforge.net/lists/listinfo/dynapi-dev
>>


> _______________________________________________
> Dynapi-Dev mailing list
> Dyn...@li...
> http://lists.sourceforge.net/lists/listinfo/dynapi-dev


----------------------
DynAPI Snapshots: http://dynapi.sourceforge.net/snapshot/
DynAPI Homepage: http://dynapi.sourceforge.net/