Jammer-Thread

[Krishty]

Jaa, es gibt ein paar Möglichkeiten … die Ressourcenerzeugung auf eigene Routinen auszulagern, die nach der Initialisierung aber vor dem Simulationsstart laufen. Und – vor allem – Zombie States. Und so. Scheiße ist nur, dass jede Lösung zig neue Probleme aufwirft. Oder aufwerfen könnte. Das übersteigt meinen gedanklichen Horizont und damit bleiben mir nur Entscheidungsparalyse oder Flucht (je nach Mondphase).

Und dieses Frame-Gepfriemel fliegt einem früher oder später um die Ohren. Wie in S.T.A.L.K.E.R., wo nach 25 Tagen in-Game-Zeit alles tot ist, weil jemand die im Spiel vergangenen Milisekunden in einer int hochzählt und die KI drauf gefußt hat. Das war aber nur ein überspitztes Beispiel; würde ich sowas tatsächlich einbauen, wäre es ein sichererer, aber auch komplexerer Mechanismus.

[CodingCat]

Blöde Frage, wieso müssen sich die Erzeuger identifizieren? Klingt nach einem ziemlich grundsätzlichen Abhängigkeitsproblem, dessen Ursache ich gerade nicht nachvollziehen kann. Wenn du jetzt massig Zombie States einführst, nur um die Erzeuger nach vollständiger Konstruktion zur Identifizierung nutzen zu können, stellt sich mir die Frage, ob die Erzeuger nicht das falsche Mittel für diese wie auch immer geartete Identifizierung sind?

[Krishty]

Bei der Erzeugung müssen sie es nicht direkt … das ist eine Folge davon, dass die Ressourcen untereinander verschränkt werden. Erzeugt man ein Objekt als Kind eines anderen Objekts, muss das Elterobjekt zur Aktualisierung erst gesperrt werden, weil die Erzeuger (Plugins) nebenläufig agieren können. Dieses Sperren muss wiederum auf jemandes Verantwortung geschehen, weil dabei Zugriff auf Daten gewährt wird, die nur für das jeweils zugreifende Plugin sichtbar sind.

Jetzt könnte ich einführen, dass Ressourcen aufgrund von internen Operationen gesperrt werden. Dann müsste ich aber den gesamten Mechanismus doppelt schreiben; einmal für interne und für „normale“ Operationen, die sich darin unterscheiden, dass im neuen Fall keine Identifizierung und keine privaten Daten herumgereicht werden können. Oder ich erzeuge ein Null-Plugin, das als Fingerpuppe für interne Operationen agiert. Aber so oder so habe ich einen Sonderfall und das macht mich kirre.

[eXile]

Ich hoffe, ihr wisst, was ihr der Welt antut.



Und ja, das ist die US-Suche.

[Krishty]

Großartig! Je mehr es wissen, desto besser. Nochmal für Google, damit nicht nur der Anti-Jammer-Thread schön weit oben ist: High-performance GPU computation on 2D textures using Compute Shader 5.0, e.g. for post processing, is impossible on AMD Hardware due to a stupid-as-fuck compiler always choosing the slowest memory path available for reading and writing and therefore prohibiting using more than 15 % of actual hardware memory bandwidth. Furthermore, AMD won't listen to any of your concerns and Microsoft won't fix any of the HLSL compiler bugs you report, which is fucking annoying because it's almost certain to encounter one once your compute shaders are more complex than an arbitrary SM 3.0 pixel shader, especially if you need group-shared memory.

Hoffentlich waren das genug Stichwörter. Achja: Besagtes Paper weiß das übrigens auch; die benutzen read-only-Texturen, wo sie können.

[Despotist]

Krishty wieder auf World Domination Tour? ;)

Ich hab mir heute mal überlegt wie ich am Anfang wegen jedem Problem was nicht hingehauen hat im Forum gefragt habe und was letztendlich an mir lag aber wo ich auch Weltverschwörung vermutet habe ;).

Irgendwann kommt dann der kritische Punkt ab dem man sich selber helfen kann (Doku, Internet, Debuggen usw).

Krishty is schon in der nächsten (letzten?) Stufe und jammert bei Microsoft und AMD im Forum weil seine Probleme nicht an ihm selber sondern an denen liegen.

Ist ein bisschen zu vergleichen mit dem Lauf des Lebens. Am Anfang hat man Windeln, Sabber und Brei, dann ein bisschen Leben wo man halbwegs selbstständig ist und vorm Ende wieder Windeln, Sabber und Brei. Diese Parallelität ist beinahe unheimlich ;).

[joggel]

Krishty wieder auf World Domination Tour? ;)

Ich hab mir heute mal überlegt wie ich am Anfang wegen jedem Problem was nicht hingehauen hat im Forum gefragt habe und was letztendlich an mir lag aber wo ich auch Weltverschwörung vermutet habe ;).

Irgendwann kommt dann der kritische Punkt ab dem man sich selber helfen kann (Doku, Internet, Debuggen usw).

Krishty is schon in der nächsten (letzten?) Stufe und jammert bei Microsoft und AMD im Forum weil seine Probleme nicht an ihm selber sondern an denen liegen.

Ist ein bisschen zu vergleichen mit dem Lauf des Lebens. Am Anfang hat man Windeln, Sabber und Brei, dann ein bisschen Leben wo man halbwegs selbstständig ist und vorm Ende wieder Windeln, Sabber und Brei. Diese Parallelität ist beinahe unheimlich ;).

LooooL :lol:

[Krishty]

Der Unterschied ist nur, dass Windeln & Brei am Lebensabend ziemlich lustig sein können, weil man sich im Rollstuhl unter der Decke einen auf die Pflegerin scheuern kann. Mir hingegen bleibt nur die verzweifelte Einsicht, dass alles – wenn überhaupt – nur langsam besser wird, und dabei ist es auch noch egal, ob mit, durch oder ohne mich. Und dazu noch bittere Ironie und jede Menge Facepalms.

Krishty is schon in der nächsten (letzten?) Stufe

Die letzte Stufe wäre, dass ich selber den Scheiß schreibe, über den sich Leute wie ich so aufregen.

[Despotist]

Der Unterschied ist nur, dass Windeln & Brei am Lebensabend ziemlich lustig sein können, weil man sich im Rollstuhl unter der Decke ...

Du musst zugeben dass dieser Unterschied ziemlich konstruiert klingt ;).

Mir hingegen bleibt nur die verzweifelte Einsicht, dass alles – wenn überhaupt – nur langsam besser wird,

Langsam ist immerhin ein Fortschritt.

Und dazu noch bittere Ironie und jede Menge Facepalms.

Das versuche ich ja zu parodieren das du dir sowas viel zu sehr zu Herzen nimmst. Wenn man Hard- und Software bis ins Letzte ausquetschen muss braucht man sich nicht wundern wenn die streikt ;).

Die letzte Stufe wäre, dass ich selber den Scheiß schreibe, über den sich Leute wie ich so aufregen.

Das hatte ich mir auch schon überlegt aber dann wärst du der "Böse" auf der anderen Seite. Bist du wirklich so verzweifelt? Und denkst du dann würde keiner über deine Arbeit hier im Thread jammern? Und gibt es überhaupt noch jemanden mit solchen Problemen? Der Jammerthread ist ja zu 95% dein Werk ;).

[Jörg]

Und gibt es überhaupt noch jemanden mit solchen Problemen?

Ja. Leider ist meine Zeit zu knapp ist, das in einem Jammer-Blog ueber AMDs OpenCL auf einer 10.1er-Karte im Zusammenspiel mit D3D10 (von 11 will ich gar nicht erst anfangen) regelmaessig festzuhalten.

[Top-OR]

Und gibt es überhaupt noch jemanden mit solchen Problemen?

Ja. Leider ist meine Zeit zu knapp, ... hier meine Probleme zu posten

DAS finde ich traurig; fast schon zum Jammern! Dieser Thread trägt im hohen Maße zu meiner regelmäßigen Belustigung bei. Und es war doch garnicht so schwer, oder? ^^

[CodingCat]

A new-expression passes the amount of space requested to the allocation function as the first argument of
type std::size_t. That argument shall be no less than the size of the object being created; it may be
greater than the size of the object being created only if the object is an array. [...]

[...]; the result of the
new-expression will be offset by this amount from the value returned by operator new[]. This overhead
may be applied in all array new-expressions, including those referencing the library function operator
new[](std::size_t, void*) and other placement allocation functions. The amount of overhead may vary
from one invocation of new to another.

Großartig, dabei hatte mir Krishtys Idee (keine Ahnung ob das noch aktuell ist, geklaut aus dem "Dampf"-Source-Paket), operator new[] für speicherausgerichtete Objekte zu überladen, so gut gefallen. Wenn das Ding nun aber ausgerichtete Adressen zurückgibt, heißt das noch lange nicht, dass schlussendlich auch das Ergebnis von new T[N] noch ausgerichtet sein wird.

Witzigerweise umschifft Visual Studio dieses Problem auch noch stillschweigend unter folgender Bedingung: Wurde die Klasse T mittels der Compiler-eigenen Erweiterung __declspec( align(alignment) ) für statische Allokationen ausgerichtet, so addiert Visual Studio einfach mal ein Vielfaches dieser Ausrichtungsangabe statt wie sonst size_t zur an operator new[] übergebenen Größe, und stellt so die Ausrichtung wieder her; und das wo laut MSDN diese Spezifikation für alle nicht-statischen Allokationen keine Rolle spielt.

Hätte ich diese new[]-Offsets nicht vor Jahren mal zufällig gesehen, wäre es mir entsprechend nicht mal aufgefallen. Bleibt die Frage, wie andere Compiler damit umgehen, und wie C++0x-Compiler das mit den neuen offiziellen Alignment-Attributen handhaben werden.

Nachtrag: Um die Unberechenbarkeit noch zu toppen, findet die beschriebene Art von magischer Ausrichtungskorrektur nur bis zu einer Ausrichtung von 16 Byte statt, danach werden einfach willkürlich immer 16 Byte draufaddiert, wenngleich dies die Ausrichtung in keinster Weise mehr retten kann, sondern allenfalls den Speicherverbrauch sinnlos in die Höhe treibt.

[Krishty]

Wegen sowas benutze ich

• keine STL mehr
• Möglichst keine manuellen new- und erst recht new []-Ausdrücke mehr
• Meine eigenen Smart-Pointer- und Container-Klassen, die ausschließlich Placement New auf ausgerichtet allokierten Speicher anwenden

new ist in C++ sowieso für den Arsch, weil es wider so ziemlich jedem anderen Paradigma der Sprache ist. Und ja, falls der Alignment-Duschngel mit C++0x nicht besser wird, bin ich mit der Standardkonformität fertig.

(Diese spezielle Problematik kannte ich beim Umstieg auf eigene Container ehrlich gesagt noch nicht einmal. Das war mehr aus einem generellen Misstrauen gegenüber dem Entwicklungsstand von C++ und der WinAPI im Bezug auf Speicherausrichtung heraus. Gut, dass du es hier nochmal erwähnst – lässt meine Meinung von C++ nochmal sinken.)

keine Ahnung ob das noch aktuell ist, geklaut aus dem "Dampf"-Source-Paket

Keine Ahnung; in den letzten fünf Monaten habe ich (am Cric Framework) nur noch Details ändern müssen. Falls Dampf länger her ist, hat sich da aber mit an Sicherheit grenzender Wahrscheinlichkeit was getan (granulierter Speicher fiele mir da ein); falls du eine neue Version des Frameworks zum Stibitzen möchtest, stelle ich gern eine online.

Ach, und da wir ja noch immer im Jammer-Thread sind: Ich habe heute abend Twilight verpasst.

[Chromanoid]

Wenn ihr so über euer "alternativloses" C++ jammert, kommt mir das immer so vor ;)

[Krishty]

Ganz vorsichtig jetzt. Wenn du jetzt noch den Namen von irgendeiner dieser Kümmelsprachen erwähnst, die überhaupt kein Alignment kennen, …

[Schrompf]

Och naja... klar sind das schon reichlich exotische Probleme, mit denen sich die Jungs da rumschlagen. Und es ist sicher frustrierend, wenn man dann permanent halbgaren SchnellHingeklatscht-Lösungen begegnet, die so in einem verdammten Compiler nie vorkommen sollten. Aber das ist ja das Schöne daran: wenn Krishty irgendwann die ganzen Probleme gelöst hat (und falls sein Framework wenigstens Interface-kompatibel ist wie z.B. die EASTL), dann greif ich mir das irgendwann mal und schmeiß ebenso die CRT und Konsorten raus. :-)

Der Wechsel auf eine andere Sprache wäre da in etwa so sinnvoll, wie wenn das Ferrari-F1-Team auf Skoda wechselt, nur weil sie bei 8000u/min ein hohes Klirren im Motor hören. Klar baut auch Skoda gute Autos, die für ne Menge Leute das Auto der Wahl darstellen. Aber darum geht's nicht.

[Chromanoid]

Aber sowas grenzgängerisches hobbymäßig zu machen scheint mir doch etwas masochistisch/selbstzerstörerisch :D Ihr seid sozusagen die waghalsigsten Extremsportler unter den Programmierern :) Zumal das ganze ja auch noch oft abhängig von technischen Details ist, die sich schnell mal ändern können...

[Schrompf]

Das stimmt wohl :-) Es ist halt ein Hobby. Ich glaube, Krishty wüsste gar nicht, was er anfangen sollte, wenn der Kram mal funktioniert.

[j.klugmann]

Mein funktionales Grafik-Layer innerhalb meiner Engine, welches die gesamte OpenGl API kapselt, bietet zum einen die Möglichkeit, das Modul im Debug Modus zu initialisieren oder nicht. Es gibt dann praktisch eine Init-Funktion, die dann mit den spezifischen Parametern aufgerufen wird, die dann den Debug-Modus ergeben. Jetzt saß ich gestern abend 2 Stunden vor der Kiste und habe mich gefragt warum zum Teufel ich verdammt nochmal kein Fenster vor die Nase geschmissen bekomme.

Habe in der spezifischen Init-Funktion nochmal alles überprüft, sogar den X-Window Code habe ich überarbeitet. Hat nichts gebracht. Letztendlich habe ich dann durch einen Zufall gesehen, dass die Debug-Modus Init-Funktion die falsche Init-Funktion kapselt. Anstatt OpenGl 3.2 zu initialisieren, hat die Funktion versucht OpenGl 4 zu initialisieren, welches noch nicht komplett implementiert ist. Argh...

[Benjamin]

"28.03.2011 13:12:59 37.2128735307s [ERROR] rwEngine::rwCGraphics::FrameStep hr = m_pSwapChain->Present(GetVSync(),0): DXGI_ERROR_DEVICE_REMOVED Hardware device removed."

Endlich mal nen Grund richtig abzulästern... ich habe nie geglaubt, dass ich eine dieser sehr sinnfreien DXGI Error Nachrichten für verschwundene Devices oder ähnliches jemals zu sehen bekomme, aber dann finde ich das auch noch in meinem eigenen Log wieder...
Das ganze von Anfang an: Heute mittag starte ich wie immer auf meinem Laptop mein Spiel und versuche grad rauszufinden, warum die Lua Callbacks nicht gehen, und auf einmal wird alles schwarz. Kein Taskmanager erscheint mehr, keine Taste reagiert... nach einer Minute bleibt sogar die Musik in einer Endlosschleife hängen -> Stecker Ziehen...
Beim Anschalten - Vertikale Muster schon im Bios-Bootscreen und mir war alles klar, nun bin ich auch dem Mega Dell-Nvidia fail der 7***er Reihe aufgesessen. Falsches Lötzinn korodiert über die Zeit bei diesen Karten. So ziemlich alle GraKas dieser Dell-Serie lösen sich mit der Zeit auf. Manche haben in der Garantiezeit schon 3/4 Stück verbraucht (von den 300€ kosten für jede GraKa mal abgesehen). man findet im Netz genug dazu...
Aber ich wollte kein Geld ausgeben, hab also einfach meine 7900GS in den Backofen getan, 40 Minuten bei 105 Grad gebacken und wieder eingebaut, siehe da: sie geht (nur wie lange noch?)
Jetzt will ich mir endlich ne FX1600M einbauen, da die DX10 kann. (Dell hatte damals noch keine standard MXM Grakas und über das Bios nur spezielle Nummern für gewisse Geräte zugelassen, deshalb ist das die beste, die ich überhaupt einbauen kann!!!)

Da komm ich mal zu der sehr sehr schlechten DX11 Doku im Bezug auf die 10Level9 Feature Levels. Ich muss ja schon zu gute halten, dass die restliche Doku eigentlich recht ausführlich ist, aber bei vielen Flags erst durch ausprobieren festzustellen dass nur bestimmte Werte zugelassen sind, dass SRGB Formate immer falsch geblendet werden, dass SurfaceSharing zwischen Devices damit nicht geht und somit auch kein DirectDraw und DirectWrite über das Teilen eines Surfaces zwischen Dx10 und Dx11 (Feature level 9_3) möglich ist, ist echt bescheiden. (vorallem dass bei manchen nur Zugriffsfehler entstehen und nichtmahl die Debug-Runtime Warnungen ausspuckt)
Ich finds trotzdem gut, dass es überhaupt geht... Ach ja... PointSprites werden ja ab DX10 nicht mehr unterstützt, man solle doch Geometry-Shader nehmen... aber wie bei FeatureLevel 9_3??? also PointSprites Camera-Aligned ... auch nicht grad sehr schnell... vorallem bei größeren Mengen...

Nochmal auf Lua zurückgehend... die Integration hab ich über folgenden sehr interessanten code eingebaut http://code.google.com/p/luawrapper/
Dort fällt auf, wie kryptisch c++0x ist, wie jeder compiler was anderes darunter versteht, dass variadic templates echt was tolles in VC10 wären, usw...

Das bringt mich gleich zur Fehlerhaften implementierung von make_pair in der 2010er stl... und da waren noch einige andere dieser Patzer für die man dann auf Connect nur lesen kann "VC11"...

alles zum kotzen...
Entschuldigt Rechtschreibung und Ausdruck zu später Stunde. Kein Bock mehr...

[CodingCat]

Code: Alles auswählen

	template <size_t Alignment>
	struct stack_aligned
	{
		LEAN_STATIC_ASSERT_MSG_ALT(false, "Alignment is required to be power of two.", Alignment_is_required_to_be_power_of_two);
	};
	// [...]
	template <> struct alignas(4) stack_aligned<4> { };
	// [...]

	struct bla : public stack_aligned<4> { ... };
	// Compiler error: Alignment is required to be power of two

Großartig, wer hat sich das denn wieder ausgedacht (steckt ein schnödes static_assert(false, ...) hinter dem Makro). So gehts:

Code: Alles auswählen

	template <size_t Alignment>
	struct stack_aligned
	{
		// Always checked if independent, therefore use static_assert with care
		LEAN_STATIC_ASSERT_MSG_ALT(Alignment & ~Alignment, // = false, dependent
			"Alignment is required to be power of two.",
			Alignment_is_required_to_be_power_of_two);
	};
	// [...]

[Krishty]

Wo wir gerade dabei sind:
template <size_t alignment> struct __declspec(align(alignment)) stackAligned { // error: expected a literal
Visual-C++-6.0-Leichen ftw!

Ich habe btw in der Basisklasse meiner ausgerichteten Typen die Operatoren Placement-new und -delete überladen und mit einer Assertion ausgestattet, die sofort fliegt, wenn die auf unausgerichtetem Speicher instanziert werden; das kann helfen, wenn man – wie ich – eh alles nur noch per Placement macht. Und ein __assume(nullptr != _Where); spart ein paar Anweisungen, falls man unter VC Placement-new benutzt.

Und vergiss nicht, dass VC eine verkrüppelte Emtpy Base Class Optimization durchführt – wenn du also nicht ein bis acht Bytes verschwenden willst, darf diese Klasse nie parallel mit anderen Klassen à INonCopyable Basis sein, sondern du musst die leeren Basisklassen verketten. Ist das nicht toll :)

[CodingCat]

Ja über diese Empty Base Class Optimization bin ich mir (wohl ebenfalls dank dir) schon länger im Klaren. Assertions in Placement New sind eine gute Idee, nur für den new[] bin ich noch am Suchen. Notfalls hilft wohl Überladen und private machen. :P

Ich hatte gehofft, dass die Größe ausgerichteter Typen immer automatisch ein positives ganzes Vielfaches ihrer Ausrichtung ist, aber leider finde ich im aktuellen Draft nichts entsprechendes. Eigentlich hätte ich ja sogar erwartet, dass alle Variationen von new bei voller Implementierung des neuen Standards von alleine auf die neuen Alignment-Angaben Rücksicht nehmen, aber auch dem scheint nicht so zu sein. Jedenfalls scheint Visual C++ ausgerichtete Strukturen automatisch mit passendem Padding zum Vielfachen zu versehen, in diesem Fall ließe sich mit relativ wenig zusätzlichen Ausrichtungsberechnungen ein falsches Offset locker aus der an new[] übergebenen Größe rausrechnen.

[Krishty]

Hätte ich diese new[]-Offsets nicht vor Jahren mal zufällig gesehen, wäre es mir entsprechend nicht mal aufgefallen. Bleibt die Frage, wie andere Compiler damit umgehen, und wie C++0x-Compiler das mit den neuen offiziellen Alignment-Attributen handhaben werden.

A new-expression passes the amount of space requested to the allocation function as the first argument of type std::size_t. That argument shall be no less than the size of the object being created; it may be greater than the size of the object being created only if the object is an array. For arrays of char and unsigned char, the difference between the result of the new-expression and the address returned by the allocation function shall be an integral multiple of the strictest fundamental alignment requirement (3.11) of any object type whose size is no greater than the size of the array being created. [Note: Because allocation functions are assumed to return pointers to storage that is appropriately aligned for objects of any type with fundamental alignment, this constraint on array allocation overhead permits the common idiom of allocating character arrays into which objects of other types will later be placed. —end note ]

Ich lese das so: new char [] und new unsigned char [] fragen bei Allokationsfunktionen so viel Puffer zusätzlich zum eigenen Speicher an, dass jeder irgendwo im Programm definierte Typ, der in die Anzahl chars passt, die der Programmierer anfordert, in diesem neuen Array ausgerichtet platziert werden kann (und das Ergebnis dieses Ausdrucks ist dann auch die ausgerichtete Adresse). Das bedeutet wiederum: C++0x unterstützt bei new Ausrichtung – allerdings nur, wenn man den Speicher per new char[sizeof(T)] anfordert und dann ein Placement new mit dem eigentlichen Typ darauf ausführt (new (new char [sizeof(T)]) T();). Ich könnte mich aber auch irren – ist schon früh – oder in Wunschbestätigung dafür verfallen, dass ich außer Placement new schon seit Monaten mit C++’ new fertig bin.

Assertions in Placement New sind eine gute Idee, nur für den new[] bin ich noch am Suchen. Notfalls hilft wohl Überladen und private machen. :P

Ich hatte gehofft, dass die Größe ausgerichteter Typen immer automatisch ein positives ganzes Vielfaches ihrer Ausrichtung ist, aber leider finde ich im aktuellen Draft nichts entsprechendes.

Mal total ins Blaue geraten: Imo ist die Größe dabei nicht ausschlaggebend – wenn ein Objekt ausgerichtet deklariert ist, kann es nur an bestimmten Adressen instanziert werden. Das bedeutet: Falls ein Array-Element kleiner ist als das kleinste Vielfache seiner Ausrichtung, hat der Compiler überhaupt keine andere Möglichkeit, als zwischen den Elementen zu padden. Das muss jedoch nicht in der Klasse über ihre Größe geschehen, sondern kann auch bei der Array-Allokation geschehen. Gleichzeitig wird jede Zeigerarithmetik diesen Typ betreffend mit dem aufgerundeten Wert arbeiten, d.h (toObj + 1) != ((char*)toObj + sizeof(*toObj)). So würde ich es jedenfalls an Stelle der Compiler-Entwickler machen, wenn ich Klassen-Padding auf Teufel-komm-raus vermeiden wollte.
Momentan ist Ausrichtung aber eh noch ein Compiler-spezifisches Feature und damit ist alles, was du in diese Richtung schreibst, höchstwahrscheinlich unbeständig.

Die Idee, über die in Placement new [] übergebene Größe die Ausrichtung zu bestimmen, ist gut. Ich frage mich nur: Kommt dort die Array-Größe mit oder ohne Unkosten zum Speichern der Array-Größe an? Dasselbe wie in nicht-Placement new [] oder ein „bereinigter“ Wert?

Wenn ich in den nächsten Tagen Zeit habe, schaue ich diesbezüglich noch tiefer in den C++0x-Entwurf.

[Despotist]

Ich schäme mich fast meine profanen Problemchen zu posten während Krishty echte Probeleme hat ;).

Habe mein System neu augesetzt (Jahreszyklus) und dabei auch auf Visual Studio 2010 Express gewechselt. Der SP1 muss dafür separat runtergeladen und installiert werden. Wenn eine neue Version verfügbar ist wieso wird das nicht gleich in den Standarddownload integriert?

Aber was mich richtig ank... ist der Firefox 4 weil da die Elemente im Kontextmenü der Links vertauscht wurden. Nun mache ich den Link anstatt im neuen Tab ständig im neuen Fenster auf was mich total nervt.

Aber ansonsten ging das Neuaufsetzen erstaunlich glatt über die Bühne.

[Chromanoid]

Aber was mich richtig ank... ist der Firefox 4 weil da die Elemente im Kontextmenü der Links vertauscht wurden. Nun mache ich den Link anstatt im neuen Tab ständig im neuen Fenster auf was mich total nervt.

Benutzt du dafür nicht einfach die mittlere Maustaste?

[Despotist]

Benutzt du dafür nicht einfach die mittlere Maustaste?

Das kannte ich noch nicht. Aber als Button nutze ich die eigentlich kaum. Nur zum scrollen (hab da regulär keinen Finger drauf). Mal sehen ob ich mir das umgewöhnen kann.

[Krishty]

"28.03.2011 13:12:59 37.2128735307s [ERROR] rwEngine::rwCGraphics::FrameStep hr = m_pSwapChain->Present(GetVSync(),0): DXGI_ERROR_DEVICE_REMOVED Hardware device removed."

Endlich mal nen Grund richtig abzulästern... ich habe nie geglaubt, dass ich eine dieser sehr sinnfreien DXGI Error Nachrichten für verschwundene Devices oder ähnliches jemals zu sehen bekomme, aber dann finde ich das auch noch in meinem eigenen Log wieder...

Die Dinger sind aber auch scheiße dokumentiert. Unter Vista und DXGI 1 gab es z.B. noch diesen Occluded-Status auf den man testen musste, falls das Fenster von einem anderen verdeckt wurde.
Ab Windows 7 und DXGI 1.1 war keine Spur mehr davon. Present() war einfach immer erfolgreich. In der Doku stand absolut garnichts in der Richtung. Also habe ich im Developer-Forum nachgefragt, ob der Occluded-Status entfernt wurde. Keine Antwort. Keine Info. Rauf- und runterprobiert, Present() fehlschlagen zu lassen, keine Chance.
Ein halbes Jahr später kracht es in meiner Engine. Present() gab den Occluded-Status zurück. Grund: Wenn man ein Programm mit Administratorrechten starten will und der UAC-Dialog aufplöppt, wird dem Desktop Window Manager die Kontrolle entzogen (damit kein Programm den UAC-Dialog fälschen kann) und alles, was in diesem Augenblick rendert, wird als occluded verworfen. Toll. Sowas kann einem auch echt keiner sagen.

Das kannte ich noch nicht. Aber als Button nutze ich die eigentlich kaum. Nur zum scrollen (hab da regulär keinen Finger drauf). Mal sehen ob ich mir das umgewöhnen kann.

Tu es; ist wirklich sehr bequem und schnell.

[kimmi]

Vielleicht wussten die das einfach auch nicht. Wir warten hier ebenfalls eine recht dicke Codebasis ( weit über 3 Mio Zeilen Code, und alles dabei, C++, Matlab, Java, Python etc. ) und da sind wir auch oft überrascht, was da alles schief gehen kann :).
Also sei nicht zu hart mit denen.

Gruß Kimmi

[Tejio]

Nichts großartiges, aber ich hab auch etwas zum Jammern:
Ich komme einfach nicht auf die Idee, wie ich an den AudioRendererHost von Chrome über Berkelium rankomme, um den Ton von Webseiten und Flash-Inhalten abzustellen.

Vielleicht finde ich auf den Entwicklerseiten zu Chromium etwas interessantes....

Gruß, Tejio ;)