Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Reihenfolge ?
21 views
Skip to first unread message
Carla Schneider
May 21, 2013, 4:06:23 AM5/21/13
to
Hier ist ein Beispiel fuer webgl, ein Interface fuer Opengl ES Rendering
auf webseiten:
http://www.ibiblio.org/e-notes/webgl/models/jupiter.html
Bisher habe ich sowas in C programmiert, aber das geht natuerlich nicht fuer
Webseiten, bzw. fuer diese Tablet-PCs die inzwischen auch nicht mehr nur Maeusekino
sind. Was ich sehr irritierend finde ist dass hier die Reihenfolge umgekehrt ist.
In C wird zuerst das array deklariert , dann gefuellt und dann an opengl uebergeben.
Hier wird das Array zuerst gefuellt, dann deklariert und dann uebergeben - zumindest sieht es so
aus:
--------------
function webGLStart() {
initGL();
var size = Math.min(window.innerWidth, window.innerHeight) - 10;
canvas.width = size; canvas.height = size;
gl.viewport(0, 0, size, size);
var texture = loadTexture("../../VRML/Globe/jup0vtt2.jpg");
var prog = gl.createProgram();
gl.attachShader(prog, getShader( gl, "shader-vs" ));
gl.attachShader(prog, getShader( gl, "shader-fs" ));
gl.linkProgram(prog);
gl.useProgram(prog);
--------
Hier werden 3 arrays gefuellt, deren Laenge offenbar egal ist:
--------
var vertices = [], texCoord = [], ind = [];
var dt = 1/nTheta, dp = 1/nPhi,
dPhi = 2*Math.PI/nPhi, dTheta = Math.PI/nTheta,
nFaces = nPhi * nTheta;
for (var j = 0; j <= nTheta; j++ ){
var Theta = j * dTheta;
var cosTheta = Math.cos ( Theta );
var sinTheta = Math.sin ( Theta );
for (var i = 0; i <= nPhi; i++ ){
var Phi = i * dPhi;
var cosPhi = Math.cos ( Phi );
var sinPhi = Math.sin ( Phi );
vertices.push( cosPhi * sinTheta );
vertices.push( -sinPhi * sinTheta );
vertices.push( cosTheta );
texCoord.push ( dp*i ); texCoord.push ( dt*(nTheta - j) );
}
}
for (var j = 0; j < nTheta; j++ )
for (var i = 0; i <= nPhi; i++ ){
ind.push( j*(nPhi+1) + i );
ind.push( (j+1)*(nPhi+1) + i );
}
var posLocation = gl.getAttribLocation(prog, "aPos");
gl.enableVertexAttribArray( posLocation );
gl.bindBuffer(gl.ARRAY_BUFFER, gl.createBuffer());
----
Und hier wird dann das Array vertices mit new offenbar erst mal erzeugt -
auch diesmal kein Hinweis auf die Laenge.
----
gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(vertices), gl.STATIC_DRAW);
gl.vertexAttribPointer(posLocation, 3, gl.FLOAT, false, 0, 0);
var texLoc = gl.getAttribLocation(prog, "aTexCoord");
gl.enableVertexAttribArray( texLoc );
gl.bindBuffer(gl.ARRAY_BUFFER, gl.createBuffer());
gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(texCoord), gl.STATIC_DRAW);
gl.vertexAttribPointer(texLoc, 2, gl.FLOAT, false, 0, 0);
gl.bindBuffer(gl.ELEMENT_ARRAY_BUFFER, gl.createBuffer());
gl.bufferData(gl.ELEMENT_ARRAY_BUFFER, new Uint16Array(ind),
gl.STATIC_DRAW);
gl.uniform1i(gl.getUniformLocation(prog, "uTexSamp"), 0);
var prMatrix = new CanvasMatrix4();
prMatrix.perspective(45, 1, .1, 100);
gl.uniformMatrix4fv( gl.getUniformLocation(prog,"prMatrix"),
false, new Float32Array(prMatrix.getAsArray()) );
rotMat.makeIdentity();
rotMat.rotate(90, 1,0,0);
mvMatLoc = gl.getUniformLocation(prog,"mvMatrix");
gl.enable(gl.DEPTH_TEST);
gl.depthFunc(gl.LEQUAL);
gl.clearDepth(1.0);
gl.clearColor(0, 0, 0, 1);
drawScene();
-------
Dass diese Funktion erst nach ihrer Verwendung deklariert wird - und zudem
innerhalb einer anderen Funktion ist auch fuer C Programmierer etwas ungewoehnlich,
aber ich schaetze das kann man auch anders machen.
-------
function loadTexture(src) {
var texture = gl.createTexture();
gl.bindTexture(gl.TEXTURE_2D, texture);
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.LINEAR);
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, gl.LINEAR);
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_S, gl.CLAMP_TO_EDGE);
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_T, gl.CLAMP_TO_EDGE);
var image = new Image();
image.src = src;
image.onload = function() {
gl.bindTexture(gl.TEXTURE_2D, texture);
gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE,
image);
// gl.texImage2D(gl.TEXTURE_2D, 0, image, true);
drawScene();
};
return texture;
}
canvas.resize = function (){
var size = Math.min(window.innerWidth, window.innerHeight) - 10;
canvas.width = size; canvas.height = size;
gl.viewport(0, 0, size, size);
drawScene();
}
}
function drawScene(){
rotMat.rotate(xRot/5, 1,0,0); rotMat.rotate(yRot/5, 0,1,0);
rotMat.rotate(zRot, 0,0,1);
yRot = xRot = zRot = 0;
mvMatrix.load( rotMat );
mvMatrix.translate(0, 0, transl);
gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT);
gl.uniformMatrix4fv( mvMatLoc, false, new Float32Array(mvMatrix.getAsArray()) );
for(var i=0; i < nTheta; i++)
gl.drawElements(gl.TRIANGLE_STRIP, nPhi2, gl.UNSIGNED_SHORT, 2*nPhi2*i);
gl.flush ();
}
auf webseiten:
http://www.ibiblio.org/e-notes/webgl/models/jupiter.html
Bisher habe ich sowas in C programmiert, aber das geht natuerlich nicht fuer
Webseiten, bzw. fuer diese Tablet-PCs die inzwischen auch nicht mehr nur Maeusekino
sind. Was ich sehr irritierend finde ist dass hier die Reihenfolge umgekehrt ist.
In C wird zuerst das array deklariert , dann gefuellt und dann an opengl uebergeben.
Hier wird das Array zuerst gefuellt, dann deklariert und dann uebergeben - zumindest sieht es so
aus:
--------------
function webGLStart() {
initGL();
var size = Math.min(window.innerWidth, window.innerHeight) - 10;
canvas.width = size; canvas.height = size;
gl.viewport(0, 0, size, size);
var texture = loadTexture("../../VRML/Globe/jup0vtt2.jpg");
var prog = gl.createProgram();
gl.attachShader(prog, getShader( gl, "shader-vs" ));
gl.attachShader(prog, getShader( gl, "shader-fs" ));
gl.linkProgram(prog);
gl.useProgram(prog);
--------
Hier werden 3 arrays gefuellt, deren Laenge offenbar egal ist:
--------
var vertices = [], texCoord = [], ind = [];
var dt = 1/nTheta, dp = 1/nPhi,
dPhi = 2*Math.PI/nPhi, dTheta = Math.PI/nTheta,
nFaces = nPhi * nTheta;
for (var j = 0; j <= nTheta; j++ ){
var Theta = j * dTheta;
var cosTheta = Math.cos ( Theta );
var sinTheta = Math.sin ( Theta );
for (var i = 0; i <= nPhi; i++ ){
var Phi = i * dPhi;
var cosPhi = Math.cos ( Phi );
var sinPhi = Math.sin ( Phi );
vertices.push( cosPhi * sinTheta );
vertices.push( -sinPhi * sinTheta );
vertices.push( cosTheta );
texCoord.push ( dp*i ); texCoord.push ( dt*(nTheta - j) );
}
}
for (var j = 0; j < nTheta; j++ )
for (var i = 0; i <= nPhi; i++ ){
ind.push( j*(nPhi+1) + i );
ind.push( (j+1)*(nPhi+1) + i );
}
var posLocation = gl.getAttribLocation(prog, "aPos");
gl.enableVertexAttribArray( posLocation );
gl.bindBuffer(gl.ARRAY_BUFFER, gl.createBuffer());
----
Und hier wird dann das Array vertices mit new offenbar erst mal erzeugt -
auch diesmal kein Hinweis auf die Laenge.
----
gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(vertices), gl.STATIC_DRAW);
gl.vertexAttribPointer(posLocation, 3, gl.FLOAT, false, 0, 0);
var texLoc = gl.getAttribLocation(prog, "aTexCoord");
gl.enableVertexAttribArray( texLoc );
gl.bindBuffer(gl.ARRAY_BUFFER, gl.createBuffer());
gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(texCoord), gl.STATIC_DRAW);
gl.vertexAttribPointer(texLoc, 2, gl.FLOAT, false, 0, 0);
gl.bindBuffer(gl.ELEMENT_ARRAY_BUFFER, gl.createBuffer());
gl.bufferData(gl.ELEMENT_ARRAY_BUFFER, new Uint16Array(ind),
gl.STATIC_DRAW);
gl.uniform1i(gl.getUniformLocation(prog, "uTexSamp"), 0);
var prMatrix = new CanvasMatrix4();
prMatrix.perspective(45, 1, .1, 100);
gl.uniformMatrix4fv( gl.getUniformLocation(prog,"prMatrix"),
false, new Float32Array(prMatrix.getAsArray()) );
rotMat.makeIdentity();
rotMat.rotate(90, 1,0,0);
mvMatLoc = gl.getUniformLocation(prog,"mvMatrix");
gl.enable(gl.DEPTH_TEST);
gl.depthFunc(gl.LEQUAL);
gl.clearDepth(1.0);
gl.clearColor(0, 0, 0, 1);
drawScene();
-------
Dass diese Funktion erst nach ihrer Verwendung deklariert wird - und zudem
innerhalb einer anderen Funktion ist auch fuer C Programmierer etwas ungewoehnlich,
aber ich schaetze das kann man auch anders machen.
-------
function loadTexture(src) {
var texture = gl.createTexture();
gl.bindTexture(gl.TEXTURE_2D, texture);
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MIN_FILTER, gl.LINEAR);
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_MAG_FILTER, gl.LINEAR);
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_S, gl.CLAMP_TO_EDGE);
gl.texParameteri(gl.TEXTURE_2D, gl.TEXTURE_WRAP_T, gl.CLAMP_TO_EDGE);
var image = new Image();
image.src = src;
image.onload = function() {
gl.bindTexture(gl.TEXTURE_2D, texture);
gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE,
image);
// gl.texImage2D(gl.TEXTURE_2D, 0, image, true);
drawScene();
};
return texture;
}
canvas.resize = function (){
var size = Math.min(window.innerWidth, window.innerHeight) - 10;
canvas.width = size; canvas.height = size;
gl.viewport(0, 0, size, size);
drawScene();
}
}
function drawScene(){
rotMat.rotate(xRot/5, 1,0,0); rotMat.rotate(yRot/5, 0,1,0);
rotMat.rotate(zRot, 0,0,1);
yRot = xRot = zRot = 0;
mvMatrix.load( rotMat );
mvMatrix.translate(0, 0, transl);
gl.clear(gl.COLOR_BUFFER_BIT | gl.DEPTH_BUFFER_BIT);
gl.uniformMatrix4fv( mvMatLoc, false, new Float32Array(mvMatrix.getAsArray()) );
for(var i=0; i < nTheta; i++)
gl.drawElements(gl.TRIANGLE_STRIP, nPhi2, gl.UNSIGNED_SHORT, 2*nPhi2*i);
gl.flush ();
}
Bjoern Hoehrmann
May 21, 2013, 5:13:49 AM5/21/13
to
* Carla Schneider wrote in de.comp.lang.javascript:
vielleicht so vorstellen:
typedef struct {
size_t L�nge;
char* Daten;
} DynamischerString;
Dazu kommen dann Funktionen die .L�nge und .Daten nur zusammen �ndern.
In deinem Beispiel kannst du dir `vertices.push(...)` so vorstellen, da
sorgt die Implementierung von `push(...)` daf�r, dass das neue Element
angeh�ngt wird und die `.length` Eigenschaft um eins erh�ht wird.
>----
>Und hier wird dann das Array vertices mit new offenbar erst mal erzeugt -
>auch diesmal kein Hinweis auf die Laenge.
>----
>
> gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(vertices), gl.STATIC_DRAW);
Das erzeugt ein neues `Float32Array` Objekt mit Daten aus `vertices`. Du
kannst dir das vielleicht so vorstellen, `var vertices = [ ... ]` ist
typedef struct {
size_t L�nge;
JSObject* Daten;
} JSObjectArray;
wohingegen ein `Float32Array` eher so aussieht:
typedef struct {
size_t L�nge;
float32* Daten;
} Float32Array;
Der Grafikchip will all die `float32`-Werte am St�ck haben. Daf�r sorgt
`new Float32Array(vertices)`, der Konstruktor macht aus jedem Element in
`vertices` einen `float32`-Wert und speichert diese an einem St�ck ab.
--
Bj�rn H�hrmann � mailto:bjo...@hoehrmann.de � http://bjoern.hoehrmann.de
Am Badedeich 7 � Telefon: +49(0)160/4415681 � http://www.bjoernsworld.de
25899 Dageb�ll � PGP Pub. KeyID: 0xA4357E78 � http://www.websitedev.de/
>Bisher habe ich sowas in C programmiert, aber das geht natuerlich nicht fuer
>Webseiten, bzw. fuer diese Tablet-PCs die inzwischen auch nicht mehr nur Maeusekino
>sind. Was ich sehr irritierend finde ist dass hier die Reihenfolge umgekehrt ist.
>In C wird zuerst das array deklariert , dann gefuellt und dann an opengl uebergeben.
>Hier wird das Array zuerst gefuellt, dann deklariert und dann uebergeben - zumindest sieht es so
>aus:
>Webseiten, bzw. fuer diese Tablet-PCs die inzwischen auch nicht mehr nur Maeusekino
>sind. Was ich sehr irritierend finde ist dass hier die Reihenfolge umgekehrt ist.
>In C wird zuerst das array deklariert , dann gefuellt und dann an opengl uebergeben.
>Hier wird das Array zuerst gefuellt, dann deklariert und dann uebergeben - zumindest sieht es so
>aus:
>Hier werden 3 arrays gefuellt, deren Laenge offenbar egal ist:
Dynamische Arrays sind auch in C nichts ungew�hnliches, man kann es sich
vielleicht so vorstellen:
typedef struct {
size_t L�nge;
char* Daten;
} DynamischerString;
Dazu kommen dann Funktionen die .L�nge und .Daten nur zusammen �ndern.
In deinem Beispiel kannst du dir `vertices.push(...)` so vorstellen, da
sorgt die Implementierung von `push(...)` daf�r, dass das neue Element
angeh�ngt wird und die `.length` Eigenschaft um eins erh�ht wird.
>----
>Und hier wird dann das Array vertices mit new offenbar erst mal erzeugt -
>auch diesmal kein Hinweis auf die Laenge.
>----
>
> gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(vertices), gl.STATIC_DRAW);
kannst dir das vielleicht so vorstellen, `var vertices = [ ... ]` ist
typedef struct {
size_t L�nge;
JSObject* Daten;
} JSObjectArray;
wohingegen ein `Float32Array` eher so aussieht:
typedef struct {
size_t L�nge;
float32* Daten;
} Float32Array;
Der Grafikchip will all die `float32`-Werte am St�ck haben. Daf�r sorgt
`new Float32Array(vertices)`, der Konstruktor macht aus jedem Element in
`vertices` einen `float32`-Wert und speichert diese an einem St�ck ab.
--
Bj�rn H�hrmann � mailto:bjo...@hoehrmann.de � http://bjoern.hoehrmann.de
Am Badedeich 7 � Telefon: +49(0)160/4415681 � http://www.bjoernsworld.de
25899 Dageb�ll � PGP Pub. KeyID: 0xA4357E78 � http://www.websitedev.de/
Carla Schneider
May 21, 2013, 5:45:15 AM5/21/13
to
Bjoern Hoehrmann wrote:
>
> * Carla Schneider wrote in de.comp.lang.javascript:
> >Bisher habe ich sowas in C programmiert, aber das geht natuerlich nicht fuer
> >Webseiten, bzw. fuer diese Tablet-PCs die inzwischen auch nicht mehr nur Maeusekino
> >sind. Was ich sehr irritierend finde ist dass hier die Reihenfolge umgekehrt ist.
> >In C wird zuerst das array deklariert , dann gefuellt und dann an opengl uebergeben.
> >Hier wird das Array zuerst gefuellt, dann deklariert und dann uebergeben - zumindest sieht es so
> >aus:
>
> >Hier werden 3 arrays gefuellt, deren Laenge offenbar egal ist:
>
> Dynamische Arrays sind auch in C nichts ungewï¿œhnliches, man kann es sich
>
> * Carla Schneider wrote in de.comp.lang.javascript:
> >Bisher habe ich sowas in C programmiert, aber das geht natuerlich nicht fuer
> >Webseiten, bzw. fuer diese Tablet-PCs die inzwischen auch nicht mehr nur Maeusekino
> >sind. Was ich sehr irritierend finde ist dass hier die Reihenfolge umgekehrt ist.
> >In C wird zuerst das array deklariert , dann gefuellt und dann an opengl uebergeben.
> >Hier wird das Array zuerst gefuellt, dann deklariert und dann uebergeben - zumindest sieht es so
> >aus:
>
> >Hier werden 3 arrays gefuellt, deren Laenge offenbar egal ist:
>
> vielleicht so vorstellen:
>
> typedef struct {
> size_t Lï¿œnge;
>
> typedef struct {
> char* Daten;
> } DynamischerString;
>
> Dazu kommen dann Funktionen die .Lï¿œnge und .Daten nur zusammen ï¿œndern.
> In deinem Beispiel kannst du dir `vertices.push(...)` so vorstellen, da
> sorgt die Implementierung von `push(...)` dafï¿œr, dass das neue Element
> angehï¿œngt wird und die `.length` Eigenschaft um eins erhï¿œht wird.
>
> >----
> >Und hier wird dann das Array vertices mit new offenbar erst mal erzeugt -
> >auch diesmal kein Hinweis auf die Laenge.
> >----
> >
> > gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(vertices), gl.STATIC_DRAW);
>
> Das erzeugt ein neues `Float32Array` Objekt mit Daten aus `vertices`. Du
> kannst dir das vielleicht so vorstellen, `var vertices = [ ... ]` ist
>
> typedef struct {
> size_t Lï¿œnge;
> >----
> >Und hier wird dann das Array vertices mit new offenbar erst mal erzeugt -
> >auch diesmal kein Hinweis auf die Laenge.
> >----
> >
> > gl.bufferData(gl.ARRAY_BUFFER, new Float32Array(vertices), gl.STATIC_DRAW);
>
> Das erzeugt ein neues `Float32Array` Objekt mit Daten aus `vertices`. Du
> kannst dir das vielleicht so vorstellen, `var vertices = [ ... ]` ist
>
> typedef struct {
> JSObject* Daten;
> } JSObjectArray;
>
> wohingegen ein `Float32Array` eher so aussieht:
>
> typedef struct {
> size_t Lï¿œnge;
> } JSObjectArray;
>
> wohingegen ein `Float32Array` eher so aussieht:
>
> typedef struct {
> float32* Daten;
> } Float32Array;
>
> Der Grafikchip will all die `float32`-Werte am Stï¿œck haben. Dafï¿œr sorgt
> `new Float32Array(vertices)`, der Konstruktor macht aus jedem Element in
> `vertices` einen `float32`-Wert und speichert diese an einem Stï¿œck ab.
D.h. sinnvoll waere es gleich das float32array herzustellen
und dort dann die Werte einzutragen - das dynamische Array und das push, kann man sich
dann sparen, die benoetigte Laenge ist auch vorher schon bekannt -
oder spricht da etwas dagegen ?
Das Beispiel ist insofern flexibler als dass es auch verwendbar waere wenn die
Zahl der Vertices nicht vorher bekannt ist. Allerdings kann ich mir vorstellen
dass gerade bei sehr grossen Arrays so auch zusaetzlich Rechenzeit und Speicherplatz
verschwendet wird.
Arno Welzel
May 22, 2013, 8:27:51 AM5/22/13
to
Am 21.05.2013 10:06, schrieb Carla Schneider:
> Hier ist ein Beispiel fuer webgl, ein Interface fuer Opengl ES Rendering
> auf webseiten:
> http://www.ibiblio.org/e-notes/webgl/models/jupiter.html
>
> Bisher habe ich sowas in C programmiert, aber das geht natuerlich nicht fuer
> Webseiten, bzw. fuer diese Tablet-PCs die inzwischen auch nicht mehr nur Maeusekino
> sind. Was ich sehr irritierend finde ist dass hier die Reihenfolge umgekehrt ist.
> In C wird zuerst das array deklariert , dann gefuellt und dann an opengl uebergeben.
Und in C++ gibt es auch dynamische Arrays (Stichwort STL), die wachsen
> Hier ist ein Beispiel fuer webgl, ein Interface fuer Opengl ES Rendering
> auf webseiten:
> http://www.ibiblio.org/e-notes/webgl/models/jupiter.html
>
> Bisher habe ich sowas in C programmiert, aber das geht natuerlich nicht fuer
> Webseiten, bzw. fuer diese Tablet-PCs die inzwischen auch nicht mehr nur Maeusekino
> sind. Was ich sehr irritierend finde ist dass hier die Reihenfolge umgekehrt ist.
> In C wird zuerst das array deklariert , dann gefuellt und dann an opengl uebergeben.
kï¿œnnen.
[...]
> Hier werden 3 arrays gefuellt, deren Laenge offenbar egal ist:
Nein, deren Lï¿œnge ist nicht egal - sie sind am Anfang leer ([]) und
werden dann eben mit Elementen gefï¿œllt (push() - fï¿œgt ein Element am
Ende ein).
> var vertices = [], texCoord = [], ind = [];
> var dt = 1/nTheta, dp = 1/nPhi,
> dPhi = 2*Math.PI/nPhi, dTheta = Math.PI/nTheta,
> nFaces = nPhi * nTheta;
> for (var j = 0; j <= nTheta; j++ ){
> var Theta = j * dTheta;
> var cosTheta = Math.cos ( Theta );
> var sinTheta = Math.sin ( Theta );
> for (var i = 0; i <= nPhi; i++ ){
> var Phi = i * dPhi;
> var cosPhi = Math.cos ( Phi );
> var sinPhi = Math.sin ( Phi );
> vertices.push( cosPhi * sinTheta );
> vertices.push( -sinPhi * sinTheta );
> vertices.push( cosTheta );
> texCoord.push ( dp*i ); texCoord.push ( dt*(nTheta - j) );
> }
> -------
> Dass diese Funktion erst nach ihrer Verwendung deklariert wird - und zudem
> innerhalb einer anderen Funktion ist auch fuer C Programmierer etwas ungewoehnlich,
> aber ich schaetze das kann man auch anders machen.
Es ist halt kein C oder C++ sondern JavaScript. Vielleicht solltest Du
> Dass diese Funktion erst nach ihrer Verwendung deklariert wird - und zudem
> innerhalb einer anderen Funktion ist auch fuer C Programmierer etwas ungewoehnlich,
> aber ich schaetze das kann man auch anders machen.
Dir einfach erstmal die Grundlagen zu JavaScript aneignen.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
Carla Schneider
May 22, 2013, 9:43:51 AM5/22/13
to
Arno Welzel wrote:
>
> Am 21.05.2013 10:06, schrieb Carla Schneider:
>
> > Hier ist ein Beispiel fuer webgl, ein Interface fuer Opengl ES Rendering
> > auf webseiten:
> > http://www.ibiblio.org/e-notes/webgl/models/jupiter.html
> >
> > Bisher habe ich sowas in C programmiert, aber das geht natuerlich nicht fuer
> > Webseiten, bzw. fuer diese Tablet-PCs die inzwischen auch nicht mehr nur Maeusekino
> > sind. Was ich sehr irritierend finde ist dass hier die Reihenfolge umgekehrt ist.
> > In C wird zuerst das array deklariert , dann gefuellt und dann an opengl uebergeben.
>
> Und in C++ gibt es auch dynamische Arrays (Stichwort STL), die wachsen
> kï¿œnnen.
Was wuerde der der "C++ Is to C as Lung Cancer Is to Lung" geschrieben hat wohl
>
> Am 21.05.2013 10:06, schrieb Carla Schneider:
>
> > Hier ist ein Beispiel fuer webgl, ein Interface fuer Opengl ES Rendering
> > auf webseiten:
> > http://www.ibiblio.org/e-notes/webgl/models/jupiter.html
> >
> > Bisher habe ich sowas in C programmiert, aber das geht natuerlich nicht fuer
> > Webseiten, bzw. fuer diese Tablet-PCs die inzwischen auch nicht mehr nur Maeusekino
> > sind. Was ich sehr irritierend finde ist dass hier die Reihenfolge umgekehrt ist.
> > In C wird zuerst das array deklariert , dann gefuellt und dann an opengl uebergeben.
>
> Und in C++ gibt es auch dynamische Arrays (Stichwort STL), die wachsen
> kï¿œnnen.
zu Javascript sagen ?
dazu kam. Das Problem ist dass javascript zunaechst gar nicht als Programmiersprache
gedacht war, sondern nur als Scriptsprache fuer Webseiten, aber heute in grossem Umfang
als solche Verwendet wird, z.B. fuer HTML5 Spiele und auch in Zukunft fuer Webgl.
Christoph Becker
May 22, 2013, 9:56:27 AM5/22/13
to
Carla Schneider wrote:
lernen solltest, ist nicht "javascript" und auch nicht im besonderen
"JavaScript", sondern ECMAScript[1].
[1] <http://www.ecma-international.org/ecma-262/5.1/>
--
Christoph M. Becker
> Arno Welzel wrote:
>> Es ist halt kein C oder C++ sondern JavaScript. Vielleicht solltest Du
>> Dir einfach erstmal die Grundlagen zu JavaScript aneignen.
>
> Ich fuerchte sowas wie Float32Array ist da gar nicht dabei - weil das erst spaeter
> dazu kam. Das Problem ist dass javascript zunaechst gar nicht als Programmiersprache
> gedacht war, sondern nur als Scriptsprache fuer Webseiten, aber heute in grossem Umfang
> als solche Verwendet wird, z.B. fuer HTML5 Spiele und auch in Zukunft fuer Webgl.
Mir scheint, dass Problem ist hier eher die Begrifflichkeit. Was Du
>> Es ist halt kein C oder C++ sondern JavaScript. Vielleicht solltest Du
>> Dir einfach erstmal die Grundlagen zu JavaScript aneignen.
>
> Ich fuerchte sowas wie Float32Array ist da gar nicht dabei - weil das erst spaeter
> dazu kam. Das Problem ist dass javascript zunaechst gar nicht als Programmiersprache
> gedacht war, sondern nur als Scriptsprache fuer Webseiten, aber heute in grossem Umfang
> als solche Verwendet wird, z.B. fuer HTML5 Spiele und auch in Zukunft fuer Webgl.
lernen solltest, ist nicht "javascript" und auch nicht im besonderen
"JavaScript", sondern ECMAScript[1].
[1] <http://www.ecma-international.org/ecma-262/5.1/>
--
Christoph M. Becker
Arno Welzel
May 22, 2013, 10:15:43 AM5/22/13
to
Am 22.05.2013 15:43, schrieb Carla Schneider:
> Arno Welzel wrote:
>>
>> Am 21.05.2013 10:06, schrieb Carla Schneider:
>>
>>> Hier ist ein Beispiel fuer webgl, ein Interface fuer Opengl ES Rendering
>>> auf webseiten:
>>> http://www.ibiblio.org/e-notes/webgl/models/jupiter.html
[...]
> Arno Welzel wrote:
>>
>> Am 21.05.2013 10:06, schrieb Carla Schneider:
>>
>>> Hier ist ein Beispiel fuer webgl, ein Interface fuer Opengl ES Rendering
>>> auf webseiten:
>>> http://www.ibiblio.org/e-notes/webgl/models/jupiter.html
>> Es ist halt kein C oder C++ sondern JavaScript. Vielleicht solltest Du
>> Dir einfach erstmal die Grundlagen zu JavaScript aneignen.
>
> Ich fuerchte sowas wie Float32Array ist da gar nicht dabei - weil das erst spaeter
> dazu kam. Das Problem ist dass javascript zunaechst gar nicht als Programmiersprache
> gedacht war, sondern nur als Scriptsprache fuer Webseiten, aber heute in grossem Umfang
> als solche Verwendet wird, z.B. fuer HTML5 Spiele und auch in Zukunft fuer Webgl.
Oder auch in Flash in Form von ActionScript. Und das schon seit vielen
>> Dir einfach erstmal die Grundlagen zu JavaScript aneignen.
>
> Ich fuerchte sowas wie Float32Array ist da gar nicht dabei - weil das erst spaeter
> dazu kam. Das Problem ist dass javascript zunaechst gar nicht als Programmiersprache
> gedacht war, sondern nur als Scriptsprache fuer Webseiten, aber heute in grossem Umfang
> als solche Verwendet wird, z.B. fuer HTML5 Spiele und auch in Zukunft fuer Webgl.
Jahren. Durch Just-In-Time-Compiler ist auch das Thema "Performance"
nicht mehr so kritisch, wie noch vor 5 oder 10 Jahren.
Und wie meinst Du die Frage zu Float32Array? Das gibt es in JavaScript
bzw. den diversen anderen ECMAScript-Implementierungen durchaus:
<https://developer.mozilla.org/en-US/docs/JavaScript/Typed_arrays/Float32Array>
<http://msdn.microsoft.com/de-de/library/ie/br212916%28v=vs.94%29.aspx>
Thomas 'PointedEars' Lahn
May 22, 2013, 12:15:41 PM5/22/13
to
Christoph Becker wrote:
> Carla Schneider wrote:
>> Arno Welzel wrote:
>>> Es ist halt kein C oder C++ sondern JavaScript. Vielleicht solltest Du
>>> Dir einfach erstmal die Grundlagen zu JavaScript aneignen.
>>
>> Ich fuerchte sowas wie Float32Array ist da gar nicht dabei - weil das
>> erst spaeter dazu kam.
Float32Array ist Bestandteil von “Typed Arrays”, einem Vorschlag der Khronos
> Carla Schneider wrote:
>> Arno Welzel wrote:
>>> Es ist halt kein C oder C++ sondern JavaScript. Vielleicht solltest Du
>>> Dir einfach erstmal die Grundlagen zu JavaScript aneignen.
>>
>> Ich fuerchte sowas wie Float32Array ist da gar nicht dabei - weil das
>> erst spaeter dazu kam.
Group, der von verschiedenen Browserherstellern implementiert wurde:
<http://www.khronos.org/registry/typedarray/specs/latest/>
Unter anderem von Mozilla.org/.com in Mozilla JavaScript (dem Nachfolger von
Netscape JavaScript):
<https://developer.mozilla.org/en-US/docs/JavaScript/Typed_arrays>
>> Das Problem ist dass javascript zunaechst gar nicht als
>> Programmiersprache gedacht war, sondern nur als Scriptsprache
>> fuer Webseiten, aber heute in grossem Umfang als solche Verwendet wird,
>> z.B. fuer HTML5 Spiele und auch in Zukunft fuer Webgl.
>
> Mir scheint, dass Problem ist hier eher die Begrifflichkeit. Was Du
> lernen solltest, ist nicht "javascript" und auch nicht im besonderen
> "JavaScript", sondern ECMAScript[1].
>
> [1] <http://www.ecma-international.org/ecma-262/5.1/>
“A scripting language is a programming language that is used to
manipulate, customise, and automate the facilities of an existing system.”
(„Eine Skriptsprache *ist eine Programmiersprache*, die benutzt wird, um die
Funktionen eines bestehenden Systems zu beeinflussen, anzupassen und zu
automatisieren.“)
Es ist daher grober Unfug zu behaupten, JavaScript wäre zunächst nicht als
Programmiersprache gedacht gewesen. Die Ursachen dafür, dass “Typed Arrays”
in ECMAScript bisher nicht spezifiziert sind, liegen ganz woanders. (Leider
sind diese Irrtümer noch immer weit verbreitet, nicht zuletzt aufgrund
sachlich fhcsaler Wikipedia-Artikel. Daher auch dieser längere Artikel.)
Tatsächlich wurde JavaScript ab Mai 1996 von Brendan Eich im Auftrag der
Netscape Communications Corporation (Netscape) als anfängerfreundliches
Pendant zu Java von Sun Microsystems Inc. entwickelt (bis Dezember 1996 noch
unter den Namen “Mocha” und “LiveScript”, bis man sich mit Sun einigte).
Das erklärt auch den Namen dieser Sprache, die zahlreichen syntaktischen
Ähnlichkeiten mit Java und die ebenso zahlreichen Unterschiede dazu. Später
(Juni 1997) wurden Netscapes JavaScript (1.1) und Microsofts erweitertes
Reverse-Engineering davon (JScript 1.0) unter dem Namen „ECMAScript“ bei der
Ecma International standardisiert (da man sich nicht auf einen Namen einigen
konnte).
Dieser Standard wurde fortan von verschiedenen Herstellern (darunter
Microsoft, Opera, Mozilla, KDE e.V., Apple und Google; zeitlich in dieser
Reihenfolge) implementiert und in deren Implementierungen auch (gemäss der
Konformitätsrichtlinien und darüber hinaus) erweitert. Einige Hersteller
nahmen sich dabei direkt Netscape/Mozilla JavaScript zum Vorbild (so wie
zuvor Microsoft). Parallel zum Standardisierungsprozess und nachfolgenden
Editionen des Standards wurden auch die Implementierungen von den jeweiligen
Herstellern weiterentwickelt, und beeinflussten bzw. beeinflussen noch heute
ihrerseits die Weiterentwicklung des Standards.
“Typed Arrays” ist eine solche Erweiterung des Standards durch
Implementierungen, die inzwischen zur Standardisierung vorgeschlagen wird¹:
<http://wiki.ecmascript.org/doku.php?id=strawman:typed_arrays>
In clientseitigen ECMAScript-Implementierungen gibt es sonst nur einen
numerischen Datentyp – Number (IEEE-754 “double precision (64 bit) floating-
point value”) – und Arrays sind nicht typisiert, können also Werte
unterschiedlichen Typs als Elemente beinhalten. Dies kann man einerseits
der angestrebten Anfängerfreundlichkeit von Netscape JavaScript zuschreiben
(grundsätzlich sind *diese* ECMAScript-Implementierungen schwach und
dynamisch typisiert; es gibt auch andere). Andererseits ist das auch die
Ursache für die Flexibilität von ECMAScript-Arrays, die sich zum Beispiel
bei JSON und MongoDb-Abfragen zeigt.
Es ist daher sinnvoll, sich mit dem Standard *und* *allen* ECMAScript-
Implementierungen (mindestens den in verbreiteten Browsern verwendeten)
auseinanderzusetzen. Denn nicht alle Implementierungen sind in allen
Features standardkonform und einige Implementierungen erweitern den
Standard. Somit handelt es sich um *unterschiedliche* Programmiersprachen.
Es gibt kein “javascript”, welches sie alle adäquat beschreiben könnte.
Die Standardkonformität von ECMAScript-Implementierungen sowie die
Unterschiede und Gemeinsamkeiten zwischen ihnen analysiere ich seit vielen
Jahren (öffentlich) mit der ECMAScript Support Matrix (und meiner darauf
basierenden und diese verbessernden Bachelor-Thesis von 2012 [noch nicht
online]):
[en] <http://PointedEars.de/es-matrix>
______
¹ Grundsätzlich ist WebGL derzeit noch experimentell und man muss wirklich
gute Gründe und noch viel mehr Wissen um hardwarenahe
Grafikprogrammierung haben, um es sinnvoll einzusetzen. Ich war vor
einem Jahr beim „Internet-Briefing“ in Zürich und der bei einem
(Schweizer) Unternehmen für WebGL-Anwendungen zuständige Entwickler
erklärte uns (anderen Webentwicklern), dass die Entwicklung sehr zeit-
und kostenaufwändig seien und die Implementierungen noch von einem Tag
auf den anderen ändern würden. Inzwischen mag sich das gebessert haben,
aber von der Standardisierung von WebGL sind wir immer noch sehr weit
entfernt. Zu unterschiedlich sind die Implementierungen und die Vielzahl
der verwendeten Frameworks. Nicht zu unterschätzen sind auch die
Anforderungen an die Grafikkarte im Vergleich zu 3D-Transformationen mit
CSS3. Jedoch gibt es inzwischen weitere Anwendungen für “Typed Arrays”.
--
PointedEars
Twitter: @PointedEars2
Please do not Cc: me. / Bitte keine Kopien per E-Mail.
Carla Schneider
May 23, 2013, 5:04:13 AM5/23/13
to
Thomas 'PointedEars' Lahn wrote:
>
> Christoph Becker wrote:
>
> > Carla Schneider wrote:
> >> Arno Welzel wrote:
> >>> Es ist halt kein C oder C++ sondern JavaScript. Vielleicht solltest Du
> >>> Dir einfach erstmal die Grundlagen zu JavaScript aneignen.
> >>
> >> Ich fuerchte sowas wie Float32Array ist da gar nicht dabei - weil das
> >> erst spaeter dazu kam.
>
> Float32Array ist Bestandteil von â??Typed Arraysâ??, einem Vorschlag der Khronos
>
> Christoph Becker wrote:
>
> > Carla Schneider wrote:
> >> Arno Welzel wrote:
> >>> Es ist halt kein C oder C++ sondern JavaScript. Vielleicht solltest Du
> >>> Dir einfach erstmal die Grundlagen zu JavaScript aneignen.
> >>
> >> Ich fuerchte sowas wie Float32Array ist da gar nicht dabei - weil das
> >> erst spaeter dazu kam.
>
> Group, der von verschiedenen Browserherstellern implementiert wurde:
>
> <http://www.khronos.org/registry/typedarray/specs/latest/>
>
> Unter anderem von Mozilla.org/.com in Mozilla JavaScript (dem Nachfolger von
> Netscape JavaScript):
>
> <https://developer.mozilla.org/en-US/docs/JavaScript/Typed_arrays>
Es gehoert also nicht zu den Grundlagen von Javascript sondern wurde spaeter
>
> <http://www.khronos.org/registry/typedarray/specs/latest/>
>
> Unter anderem von Mozilla.org/.com in Mozilla JavaScript (dem Nachfolger von
> Netscape JavaScript):
>
> <https://developer.mozilla.org/en-US/docs/JavaScript/Typed_arrays>
eingebaut, wegen Webgl.
>
> >> Das Problem ist dass javascript zunaechst gar nicht als
> >> Programmiersprache gedacht war, sondern nur als Scriptsprache
> >> fuer Webseiten, aber heute in grossem Umfang als solche Verwendet wird,
> >> z.B. fuer HTML5 Spiele und auch in Zukunft fuer Webgl.
> >
> > Mir scheint, dass Problem ist hier eher die Begrifflichkeit. Was Du
> > lernen solltest, ist nicht "javascript" und auch nicht im besonderen
> > "JavaScript", sondern ECMAScript[1].
das ist es auch worum es mir geht, und das war auch die urspruengliche Anwendung.
Die anderen kamen spaeter.
> >
> > [1] <http://www.ecma-international.org/ecma-262/5.1/>
>
> â?¦ wo man unter anderem lesen kann:
>
> â??A scripting lanÂguage is a proÂgramÂming language that is used to
> manipulate, customise, and automate the facilities of an existing system.â??
>
> (â??Eine Skriptsprache *ist eine Programmiersprache*, die benutzt wird, um die
> Funktionen eines bestehenden Systems zu beeinflussen, anzupassen und zu
> automatisieren.â??)
In dem Fall also das System Webbrowser und das Ziel ist es Webseiten darzustellen.
Also urspruenglich eher vergleichbar mit sowas wie TeX.
Als "richtige" Programmiersprache haette sie sowas wie typed Array schon von Anfang
an enthalten muessen. Das war nicht so weil man Webseiten frueher allein durch
Text (HTML) beschreiben konnte. Erst Webgl schuf den Bedarf eines Formats fuer
Binaerdaten.
>
> Es ist daher grober Unfug zu behaupten, JavaScript wäre zunächst nicht als
> Programmiersprache gedacht gewesen. Die Ursachen dafür, dass â??Typed Arraysâ??
> in ECMAScript bisher nicht spezifiziert sind, liegen ganz woanders. (Leider
> sind diese Irrtümer noch immer weit verbreitet, nicht zuletzt aufgrund
> sachlich fhcsaler Wikipedia-Artikel. Daher auch dieser längere Artikel.)
>
> Tatsächlich wurde JavaScript ab Mai 1996 von Brendan Eich im Auftrag der
> Netscape Communications Corporation (Netscape) als anfängerfreundliches
> Pendant zu Java von Sun Microsystems Inc. entwickelt (bis Dezember 1996 noch
> unter den Namen â??Mochaâ?? und â??LiveScriptâ??, bis man sich mit Sun einigte).
> Das erklärt auch den Namen dieser Sprache, die zahlreichen syntaktischen
> �hnlichkeiten mit Java und die ebenso zahlreichen Unterschiede dazu. Später
> (Juni 1997) wurden Netscapes JavaScript (1.1) und Microsofts erweitertes
> Reverse-Engineering davon (JScript 1.0) unter dem Namen â??ECMAScriptâ?? bei der
> Ecma International standardisiert (da man sich nicht auf einen Namen einigen
> konnte).
>
> Dieser Standard wurde fortan von verschiedenen Herstellern (darunter
> Microsoft, Opera, Mozilla, KDE e.V., Apple und Google; zeitlich in dieser
> Reihenfolge) implementiert und in deren Implementierungen auch (gemäss der
> konnte).
>
> Dieser Standard wurde fortan von verschiedenen Herstellern (darunter
> Microsoft, Opera, Mozilla, KDE e.V., Apple und Google; zeitlich in dieser
> Konformitätsrichtlinien und darüber hinaus) erweitert. Einige Hersteller
> nahmen sich dabei direkt Netscape/Mozilla JavaScript zum Vorbild (so wie
> zuvor Microsoft). Parallel zum Standardisierungsprozess und nachfolgenden
> Editionen des Standards wurden auch die Implementierungen von den jeweiligen
> Herstellern weiterentwickelt, und beeinflussten bzw. beeinflussen noch heute
> ihrerseits die Weiterentwicklung des Standards.
Wahrscheinlich war Microsoft die bremsende Kraft, weil die kein
> zuvor Microsoft). Parallel zum Standardisierungsprozess und nachfolgenden
> Editionen des Standards wurden auch die Implementierungen von den jeweiligen
> Herstellern weiterentwickelt, und beeinflussten bzw. beeinflussen noch heute
> ihrerseits die Weiterentwicklung des Standards.
Interesse an Webgl hatten, das ja auf Opengl aufbaut, waehrend Microsoft
die 3D Grafik ueber DirectX macht und deshalb keine Webgl unterstuetzung
in IE einbaute. Aber inzwischen haben sie wohl eingesehen dass sie
da auch mitmachen muessen.
>
> â??Typed Arraysâ?? ist eine solche Erweiterung des Standards durch
> Implementierungen, die inzwischen zur Standardisierung vorgeschlagen wird¹:
>
> <http://wiki.ecmascript.org/doku.php?id=strawman:typed_arrays>
>
> In clientseitigen ECMAScript-Implementierungen gibt es sonst nur einen
> numerischen Datentyp â?? Number (IEEE-754 â??double precision (64 bit) floating-
> <http://wiki.ecmascript.org/doku.php?id=strawman:typed_arrays>
>
> In clientseitigen ECMAScript-Implementierungen gibt es sonst nur einen
> point valueâ??) â?? und Arrays sind nicht typisiert, können also Werte
> unterschiedlichen Typs als Elemente beinhalten. Dies kann man einerseits
> der angestrebten Anfängerfreundlichkeit von Netscape JavaScript zuschreiben
> (grundsätzlich sind *diese* ECMAScript-Implementierungen schwach und
> dynamisch typisiert; es gibt auch andere). Andererseits ist das auch die
> Ursache für die Flexibilität von ECMAScript-Arrays, die sich zum Beispiel
> bei JSON und MongoDb-Abfragen zeigt.
>
> Es ist daher sinnvoll, sich mit dem Standard *und* *allen* ECMAScript-
> Implementierungen (mindestens den in verbreiteten Browsern verwendeten)
> auseinanderzusetzen. Denn nicht alle Implementierungen sind in allen
> Features standardkonform und einige Implementierungen erweitern den
> Standard. Somit handelt es sich um *unterschiedliche* Programmiersprachen.
> Es gibt kein â??javascriptâ??, welches sie alle adäquat beschreiben könnte.
>
> Es ist daher sinnvoll, sich mit dem Standard *und* *allen* ECMAScript-
> Implementierungen (mindestens den in verbreiteten Browsern verwendeten)
> auseinanderzusetzen. Denn nicht alle Implementierungen sind in allen
> Features standardkonform und einige Implementierungen erweitern den
> Standard. Somit handelt es sich um *unterschiedliche* Programmiersprachen.
Wenn die sich an den Standard gehalten haetten, gaebe es kein Webgl.
>
> Die Standardkonformität von ECMAScript-Implementierungen sowie die
> Unterschiede und Gemeinsamkeiten zwischen ihnen analysiere ich seit vielen
> Jahren (öffentlich) mit der ECMAScript Support Matrix (und meiner darauf
> basierenden und diese verbessernden Bachelor-Thesis von 2012 [noch nicht
> online]):
>
> [en] <http://PointedEars.de/es-matrix>
>
> ______
> ¹ Grundsätzlich ist WebGL derzeit noch experimentell und man muss wirklich
> online]):
>
> [en] <http://PointedEars.de/es-matrix>
>
> ______
> gute Gründe und noch viel mehr Wissen um hardwarenahe
> Grafikprogrammierung haben, um es sinnvoll einzusetzen.
Gute Gruende sieht man sofort wenn man sich die Beispiele auf
http://www.ibiblio.org/e-notes/webgl/webgl.htm ansieht.
> Ich war vor
> einem Jahr beim â??Internet-Briefingâ?? in Zürich und der bei einem
> (Schweizer) Unternehmen für WebGL-Anwendungen zuständige Entwickler
> erklärte uns (anderen Webentwicklern), dass die Entwicklung sehr zeit-
> und kostenaufwändig seien und die Implementierungen noch von einem Tag
> auf den anderen ändern würden. Inzwischen mag sich das gebessert haben,
> aber von der Standardisierung von WebGL sind wir immer noch sehr weit
> entfernt. Zu unterschiedlich sind die Implementierungen und die Vielzahl
> der verwendeten Frameworks.
Die koennen ja auch unterschiedlich sein, Hauptsache sie laufen
> entfernt. Zu unterschiedlich sind die Implementierungen und die Vielzahl
> der verwendeten Frameworks.
auf Firefox und Chrome , das reicht offenbar um Microsoft auch zum
Mitmachen zu bringen.
> Nicht zu unterschätzen sind auch die
> Anforderungen an die Grafikkarte im Vergleich zu 3D-Transformationen mit
> CSS3.
Also ich habe nur die in der Intel-CPU eingebaute Grafik, das reicht, d.h. ausreichende
> CSS3.
Grafikfaehigkeiten sollte jeder PC der nicht aelter als 2 Jahre ist haben.
Das mit dem CSS3 und HTML5 scheint wohl bis vor kurzem eine Spezialitaet des
Safari Browsers gewesen zu sein den ich nicht verwende - weil es ihn fuer Linux
gar nicht gab (gibt?). Die Beispiele machen einen langsamen Eindruck - verwendet der
am Ende gar keine 3D Beschleunigung durch die Grafikkarte unter Firefox auf Linux ?
> Jedoch gibt es inzwischen weitere Anwendungen für â??Typed Arraysâ??.
Die braucht man wenn man Binaerdaten lesen,schreiben oder erzeugen will,
z.B. fuer Audio, nur falls es sich dabei um 8 Bit Integer Zahlen handelt gab
es schon vorher eine Methode.
Thomas 'PointedEars' Lahn
May 23, 2013, 5:12:35 AM5/23/13
to
Carla Schneider schrieb:
> [groben Unfug]
Du schreibst wie die Blinde von der Farbe. Wahrscheinlich willst Du wieder
nur trollen. GEH WEG.
--
PointedEars, fuppend°
> [groben Unfug]
Du schreibst wie die Blinde von der Farbe. Wahrscheinlich willst Du wieder
nur trollen. GEH WEG.
--
PointedEars, fuppend°
Carla Schneider
May 23, 2013, 6:30:06 AM5/23/13
to
Thomas 'PointedEars' Lahn wrote:
>
> Carla Schneider schrieb:
>
> > [groben Unfug]
>
> Du schreibst wie die Blinde von der Farbe. Wahrscheinlich willst Du wieder
> nur trollen. GEH WEG.
Und du bist offenbar einer von denen die die User aus dem Usenet verscheuchen wollen,
>
> Carla Schneider schrieb:
>
> > [groben Unfug]
>
> Du schreibst wie die Blinde von der Farbe. Wahrscheinlich willst Du wieder
> nur trollen. GEH WEG.
wobei sich mir der Sinn und Zweck solcher Aktionen gerade heute, wo die Zahl der User
sowieso abnimmt sich mir nicht erschliesst.
Neue User die du verscheuchen kannst gibst im Usenet sowieso keine mehr, die meisten
waren schon im letzten Jahrtausend hier.
Thomas 'PointedEars' Lahn
May 23, 2013, 6:39:07 AM5/23/13
to
„Carla Schneider“ trollte mal wieder:
<http://einklich.net/usenet/begriffe.htm#troll>
+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT | :.:\:\:/:/:.:
| FEED THE TROLLS¹ | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
==================================================================
_____
¹ ausser in jener Gruppe°, wo° das on-topic° ist
+-------------------+ .:\:\:/:/:.
| PLEASE DO NOT | :.:\:\:/:/:.:
| FEED THE TROLLS¹ | :=.' - - '.=:
| | '=(\ 9 9 /)='
| Thank you, | ( (_) )
| Management | /`-vvv-'\
+-------------------+ / \
| | @@@ / /|,,,,,|\ \
| | @@@ /_// /^\ \\_\
@x@@x@ | | |/ WW( ( ) )WW
\||||/ | | \| __\,,\ /,,/__
\||/ | | | (______Y______)
/\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
==================================================================
_____
¹ ausser in jener Gruppe°, wo° das on-topic° ist
Arno Welzel
May 23, 2013, 6:51:14 AM5/23/13
to
Am 23.05.2013 11:04, schrieb Carla Schneider:
> Thomas 'PointedEars' Lahn wrote:
[...]
Grundlagen einer Sprache zu befassen, wenn man man sich über den Code
wundert und die Reihenfolge von Dingen "irritierend" findet?
Dass Float32Array später dazugekommen ist, kann man ja auch leicht
herausfinden - die bevorzute Suchmaschine hilft da sicher gerne weiter.
So wie Du argumentierst, wäre es auch unsinnig, sich mit den Grundlagen
von HTML zu befassen, weil HTML 5 neue Dinge definiert, die ursprünglich
noch nicht vorgesehen waren und man vielleicht aus
Kompatibilitätsgründen lieber HTML 4 oder XHTML 1.0 verwenden will.
[...]
hängt aber vom Browser ab. Das ist oft JavaScript, kann aber auch
JScript sein. Und selbst dann hängt es noch von der Browser-Version ab,
was im Detail unterstützt wird.
[...]
Konstrukt zu "typed array"?
[...]
WebGL zu unterstützen oder nicht, hindert andere Hersteller ja nicht
daran, dies selbst zu tun.
Und dass Microsoft gegen WebGL ist, begründen sie nicht so sehr mit
DirectX ja oder nein, sondern mit der potentiellen Sicherheitsprobleme
bei der Ausführung von Shadern - und da gab es Anfangs durchaus sehr
konkrete Lücken, die z.B. das Auslesen des Bildschirminhaltes per
JavaScript ermöglicht hat.
Firefox setzt unter Windows für WebGL übrigens auch auf DirectX auf -
auch wenn das nur die Zwischenschicht ANGLE läuft - siehe auch
<http://code.google.com/p/angleproject/>.
[...]
verboten, den Standard zu erweitern - aber sollte mindestens den
Standard vollständig unterstützen. Ein Browser, der neben HTML 4.01 und
XHTML 1.0 auch HTML 5 unterstützt, ist ja nicht weniger standardkonform
bzgl. HTML 4.01 und XHTML 1.0, nur weil er zusätzlich auch HTML 5 versteht.
[...]
bekannten Plattformen, die WebGL unterstützen, inkl. Opera Mobile auf
Android (zumindest bis Version 12, die Version 14 ist offenbar noch
nicht ganz ausgereift):
<http://arnowelzel.de/wiki/de/web/webglsample>
Das habe ich im Mai 2011 gebaut - also schon vor rund zwei Jahren. Seit
dem musste ich da nie etwas ändern, weil sich die Umgebung verändert
hätte. Ich habe nur irgendwann mal Antialiasing zusätzlich aufgenommen
und die Knöpfe für Vollbildmodus und das Zurücksetzen der Animation.
> Die koennen ja auch unterschiedlich sein, Hauptsache sie laufen
> auf Firefox und Chrome , das reicht offenbar um Microsoft auch zum
> Mitmachen zu bringen.
Bis jetzt offenbar nicht. Es gibt Gerüchte, dass der Internet Explorer
11 auch WebGL unterstützen wird - aber die derzeit offiziellen Versionen
tun das noch nicht.
>> Nicht zu unterschätzen sind auch die
>> Anforderungen an die Grafikkarte im Vergleich zu 3D-Transformationen mit
>> CSS3.
>
> Also ich habe nur die in der Intel-CPU eingebaute Grafik, das reicht, d.h. ausreichende
> Grafikfaehigkeiten sollte jeder PC der nicht aelter als 2 Jahre ist haben.
Für simple 3D-Grafik reicht das sicher. Aber Onboard-Grafik dürfte
spätestens bei aufwendigeren Shadern komplett überfordert sein - und die
werden auch bei WebGL-Anwendungen zunehmend auch genutzt, weil eben
viele Nutzer entsprechend leistungsfähige Hardware haben.
> Thomas 'PointedEars' Lahn wrote:
[...]
>> Float32Array ist Bestandteil von â??Typed Arraysâ??, einem Vorschlag der Khronos
>> Group, der von verschiedenen Browserherstellern implementiert wurde:
>>
>> <http://www.khronos.org/registry/typedarray/specs/latest/>
>>
>> Unter anderem von Mozilla.org/.com in Mozilla JavaScript (dem Nachfolger von
>> Netscape JavaScript):
>>
>> <https://developer.mozilla.org/en-US/docs/JavaScript/Typed_arrays>
>
> Es gehoert also nicht zu den Grundlagen von Javascript sondern wurde spaeter
> eingebaut, wegen Webgl.
Ja und? Was ändert das daran, dass es sinnvoll ist, sich mit den
>> Group, der von verschiedenen Browserherstellern implementiert wurde:
>>
>> <http://www.khronos.org/registry/typedarray/specs/latest/>
>>
>> Unter anderem von Mozilla.org/.com in Mozilla JavaScript (dem Nachfolger von
>> Netscape JavaScript):
>>
>> <https://developer.mozilla.org/en-US/docs/JavaScript/Typed_arrays>
>
> Es gehoert also nicht zu den Grundlagen von Javascript sondern wurde spaeter
> eingebaut, wegen Webgl.
Grundlagen einer Sprache zu befassen, wenn man man sich über den Code
wundert und die Reihenfolge von Dingen "irritierend" findet?
Dass Float32Array später dazugekommen ist, kann man ja auch leicht
herausfinden - die bevorzute Suchmaschine hilft da sicher gerne weiter.
So wie Du argumentierst, wäre es auch unsinnig, sich mit den Grundlagen
von HTML zu befassen, weil HTML 5 neue Dinge definiert, die ursprünglich
noch nicht vorgesehen waren und man vielleicht aus
Kompatibilitätsgründen lieber HTML 4 oder XHTML 1.0 verwenden will.
[...]
>>> Mir scheint, dass Problem ist hier eher die Begrifflichkeit. Was Du
>>> lernen solltest, ist nicht "javascript" und auch nicht im besonderen
>>> "JavaScript", sondern ECMAScript[1].
>
> Im Sourcecode von Webseiten steht immer: <script type="text/javascript"> und
> das ist es auch worum es mir geht, und das war auch die urspruengliche Anwendung.
> Die anderen kamen spaeter.
"text/javascript" ist nur ein MIME-Type. Die dahinterstehende Sprache
>>> lernen solltest, ist nicht "javascript" und auch nicht im besonderen
>>> "JavaScript", sondern ECMAScript[1].
>
> Im Sourcecode von Webseiten steht immer: <script type="text/javascript"> und
> das ist es auch worum es mir geht, und das war auch die urspruengliche Anwendung.
> Die anderen kamen spaeter.
hängt aber vom Browser ab. Das ist oft JavaScript, kann aber auch
JScript sein. Und selbst dann hängt es noch von der Browser-Version ab,
was im Detail unterstützt wird.
[...]
> Als "richtige" Programmiersprache haette sie sowas wie typed Array schon von Anfang
> an enthalten muessen. Das war nicht so weil man Webseiten frueher allein durch
> Text (HTML) beschreiben konnte. Erst Webgl schuf den Bedarf eines Formats fuer
> Binaerdaten.
Hmmm - haben alle "richtigen" Programmiersprachen ein äquivalentes
> an enthalten muessen. Das war nicht so weil man Webseiten frueher allein durch
> Text (HTML) beschreiben konnte. Erst Webgl schuf den Bedarf eines Formats fuer
> Binaerdaten.
Konstrukt zu "typed array"?
[...]
>> zuvor Microsoft). Parallel zum Standardisierungsprozess und nachfolgenden
>> Editionen des Standards wurden auch die Implementierungen von den jeweiligen
>> Herstellern weiterentwickelt, und beeinflussten bzw. beeinflussen noch heute
>> ihrerseits die Weiterentwicklung des Standards.
>
> Wahrscheinlich war Microsoft die bremsende Kraft, weil die kein
> Interesse an Webgl hatten, das ja auf Opengl aufbaut, waehrend Microsoft
> die 3D Grafik ueber DirectX macht und deshalb keine Webgl unterstuetzung
> in IE einbaute. Aber inzwischen haben sie wohl eingesehen dass sie
> da auch mitmachen muessen.
Bezogen auf ECMAScript ist das unsinnig. Ob Microsoft nun gewillt ist,
>> Editionen des Standards wurden auch die Implementierungen von den jeweiligen
>> Herstellern weiterentwickelt, und beeinflussten bzw. beeinflussen noch heute
>> ihrerseits die Weiterentwicklung des Standards.
>
> Wahrscheinlich war Microsoft die bremsende Kraft, weil die kein
> Interesse an Webgl hatten, das ja auf Opengl aufbaut, waehrend Microsoft
> die 3D Grafik ueber DirectX macht und deshalb keine Webgl unterstuetzung
> in IE einbaute. Aber inzwischen haben sie wohl eingesehen dass sie
> da auch mitmachen muessen.
WebGL zu unterstützen oder nicht, hindert andere Hersteller ja nicht
daran, dies selbst zu tun.
Und dass Microsoft gegen WebGL ist, begründen sie nicht so sehr mit
DirectX ja oder nein, sondern mit der potentiellen Sicherheitsprobleme
bei der Ausführung von Shadern - und da gab es Anfangs durchaus sehr
konkrete Lücken, die z.B. das Auslesen des Bildschirminhaltes per
JavaScript ermöglicht hat.
Firefox setzt unter Windows für WebGL übrigens auch auf DirectX auf -
auch wenn das nur die Zwischenschicht ANGLE läuft - siehe auch
<http://code.google.com/p/angleproject/>.
[...]
>> Es ist daher sinnvoll, sich mit dem Standard *und* *allen* ECMAScript-
>> Implementierungen (mindestens den in verbreiteten Browsern verwendeten)
>> auseinanderzusetzen. Denn nicht alle Implementierungen sind in allen
>> Features standardkonform und einige Implementierungen erweitern den
>> Standard. Somit handelt es sich um *unterschiedliche* Programmiersprachen.
>> Es gibt kein â??javascriptâ??, welches sie alle adäquat beschreiben könnte.
>
> Wenn die sich an den Standard gehalten haetten, gaebe es kein Webgl.
Standards sind primär der kleinste gemeinsame Nenner. Es ist nicht
>> Implementierungen (mindestens den in verbreiteten Browsern verwendeten)
>> auseinanderzusetzen. Denn nicht alle Implementierungen sind in allen
>> Features standardkonform und einige Implementierungen erweitern den
>> Standard. Somit handelt es sich um *unterschiedliche* Programmiersprachen.
>> Es gibt kein â??javascriptâ??, welches sie alle adäquat beschreiben könnte.
>
> Wenn die sich an den Standard gehalten haetten, gaebe es kein Webgl.
verboten, den Standard zu erweitern - aber sollte mindestens den
Standard vollständig unterstützen. Ein Browser, der neben HTML 4.01 und
XHTML 1.0 auch HTML 5 unterstützt, ist ja nicht weniger standardkonform
bzgl. HTML 4.01 und XHTML 1.0, nur weil er zusätzlich auch HTML 5 versteht.
[...]
>> einem Jahr beim â??Internet-Briefingâ?? in Zürich und der bei einem
>> (Schweizer) Unternehmen für WebGL-Anwendungen zuständige Entwickler
>> erklärte uns (anderen Webentwicklern), dass die Entwicklung sehr zeit-
>> und kostenaufwändig seien und die Implementierungen noch von einem Tag
>> auf den anderen ändern würden. Inzwischen mag sich das gebessert haben,
>> aber von der Standardisierung von WebGL sind wir immer noch sehr weit
>> entfernt. Zu unterschiedlich sind die Implementierungen und die Vielzahl
>> der verwendeten Frameworks.
Also dieses - zugegebenermaßen simple - Beispiel läuft auf allen mir
>> (Schweizer) Unternehmen für WebGL-Anwendungen zuständige Entwickler
>> erklärte uns (anderen Webentwicklern), dass die Entwicklung sehr zeit-
>> und kostenaufwändig seien und die Implementierungen noch von einem Tag
>> auf den anderen ändern würden. Inzwischen mag sich das gebessert haben,
>> aber von der Standardisierung von WebGL sind wir immer noch sehr weit
>> entfernt. Zu unterschiedlich sind die Implementierungen und die Vielzahl
>> der verwendeten Frameworks.
bekannten Plattformen, die WebGL unterstützen, inkl. Opera Mobile auf
Android (zumindest bis Version 12, die Version 14 ist offenbar noch
nicht ganz ausgereift):
<http://arnowelzel.de/wiki/de/web/webglsample>
Das habe ich im Mai 2011 gebaut - also schon vor rund zwei Jahren. Seit
dem musste ich da nie etwas ändern, weil sich die Umgebung verändert
hätte. Ich habe nur irgendwann mal Antialiasing zusätzlich aufgenommen
und die Knöpfe für Vollbildmodus und das Zurücksetzen der Animation.
> Die koennen ja auch unterschiedlich sein, Hauptsache sie laufen
> auf Firefox und Chrome , das reicht offenbar um Microsoft auch zum
> Mitmachen zu bringen.
11 auch WebGL unterstützen wird - aber die derzeit offiziellen Versionen
tun das noch nicht.
>> Nicht zu unterschätzen sind auch die
>> Anforderungen an die Grafikkarte im Vergleich zu 3D-Transformationen mit
>> CSS3.
>
> Also ich habe nur die in der Intel-CPU eingebaute Grafik, das reicht, d.h. ausreichende
> Grafikfaehigkeiten sollte jeder PC der nicht aelter als 2 Jahre ist haben.
spätestens bei aufwendigeren Shadern komplett überfordert sein - und die
werden auch bei WebGL-Anwendungen zunehmend auch genutzt, weil eben
viele Nutzer entsprechend leistungsfähige Hardware haben.
0 new messages