 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Rolf Magnus
Guest
|
 Posted: Mon Sep 01, 2003 5:50 pm Post subject: Re: Design-Fehler? Grafikfunktionen |
 |
|
Günther wrote:
| Quote: | Ich entwickle selber eine neue C++ Bibliothek wie MFC nur besser 
|
Ist wohl nicht besonders schwer. :-)
| Quote: | Diese soll auf mehrere Betriebsstemen laufen.
2 wichtige Klassen sind
Klasse Bitmap
|
Ich glaube nicht, daß du mit dem, was du hier als Bitmap bezeichnest,
wirklich eine Bitmap meinst. Eine Bitmap beschreibt ein Feld, bei dem
jedes Element durch genau ein Bit repräsentiert wird. Im Bezug auf
Pixelgrafik ist eine Bitmap also eine Map mit einem Bit pro Pixel. Lass
dich hier nicht von Microsoft verleiten, den Begriff auch falsch zu
verwenden. Außerhalb der Microsoft-Welt wird hier meist von Pixmap
gesprochen (Also Map aus Pixeln).
| Quote: | Daten
Breite und Höhe eines Bitmaps
Bitmap-Daten selber
Methoden
...
Funktionen zum Laden und Speichern von Bitmaps (.bmp, .gif, ...)
|
Evtl. wäre es besser, Lade- und Speicherklassen zu machen, die von einer
gemeinsamen Basisklasse abgeleitet sind. Der Pixmap sollte es
eigentlich egal sein, in welchen Formaten sie aus Dateien gelesen bzw.
in solche geschrieben werden können. Vor allem sollte man nicht die
Klasse ändern müssen, um ein neues Format zu unterstützen. Das wäre
übrigens auch schlecht zwecks Binärkompatibilität.
Im Optimalfall kann man Grafikformate dynamisch als Plugin
nachinstallieren.
| Quote: | Zeichenfunktionen (zB Pixel, Linien, Dreiecke,
Funktionen mit Anti-Aliasing, Alpha-Blending, ...)
|
Bei Qt gibts für Zeichefunktionen eine eigene Klasse QPainter, die das
Zeichnen allgemein übernimmt. Die muß natürlich "hinter den Kulissen"
abhängig davon wohin gezeichnet werden soll Das Richtige (tm) tun.
| Quote: | Klasse Visual
Ist die Basisklasse aller Fenster, vergleichbar mit CWnd in MFC.
Damit ein flickerfreies Zeichen auf dem Bildschirm möglich ist,
wird zuerst in den Speicher gezeichnet und dann erst das Ergebnis auf
den Bildschirm kopiert.
In Windows verwende ich für die gepufferten Grafikfunktionen ein DC
(device context) im Speicher.
Daten
Zeiger auf das "Vater-Fenster", verkettete Liste mit anderen
"Kind-Fenstern"
Zeiger auf Desktop
DC für die gepufferte Grafikfunktionen
Methoden
...
Zeichenfunktionen (zB Pixel, Linien, Dreiecke,
Funktionen mit Anti-Aliasing, Alpha-Blending, ...)
So nun meine Idee
Da die Klasse Visual sowieso in den Puffer zeichnet könnte man sie
gleich von der Klasse Bitmap ableiten.
Vorteil
Vom Betriebssystem benötige ich nur noch die Funktion zum Kopieren
der Bitmaps auf den Bildschirm => viel einfacher portierbar.
Das System wird damit viel einfacher.
|
Eigentlich wird es viel komplexer. Denke daran, daß du dann alles selber
machen mußt - z.B. das Font-Rendering.
| Quote: | Bei Direct-Draw wird sowieso in der Anwendung gezeichnet.
Nachteil
Ich muss alle Grafikfunktionen selber schreiben.
|
Außerdem werden sie viel langsamer, da sie nicht mehr in der Grafikkarte
ausgeführt werden können. Im Prinzip verlierst du fast die gesame
Grafikbeschleunigung. Ich kenn mich mit Windows nicht so aus. Unter X
kann ich in eine Pixmap genauso rendern wie in ein Fenster. So kann man
dann auch das Double Buffering realisieren: Man rendert in eine Pixmap
und blittet die dann ins Fenster. Da das alles auf der Grafikkarte
stattfinden kann, läßt sich das sehr gut beschleunigen.
| Quote: | Fragen
Ist die Idee gut oder das ein Design-Fehler?
Beispiel Windows MFC
Warum gibt es da eine Fenster-Klasse (CWnd) und einen Context (CDC)?
In Win32 eben WND und DC.
Warum verwendet man dafür nicht eine gemeinsame Klasse?
|
Vielleicht, damit man auch noch in andere Sachen als Fenster rendern
kann. Was ist z.B. mit einem Drucker?
| Quote: | Wie sollte man die Klassen Bitmap, Context und Visual in Relation
setzen?
In welcher Klasse sollte eine Koordinatentransformation
implementiert werden, zB für Diagramme?
Soll zB die Klasse Diagram von Visual abgeleitet werden oder von
Bitmap? Ich möchte ja Diagramme generieren von Kommandozeilentools.
|
Du könntest z.B. Visual und Pixmap (und alles, wo man reinzeichnen
können soll) von einer gemeinsamen Basisklasse ableiten und dann
Diagramm ganz aus dieser Hierarchie rausnehmen. Das Diagramm-Objekt
enthält nur die Werte und Infos darüber, wie diese visualisiert werden
sollen. Gerendert wird dann in ein Objekt der obigen Basisklasse.
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
 |
Ludwig Pumberger
Guest
|
| Posted: Mon Sep 01, 2003 6:07 pm Post subject: Re: Design-Fehler? Grafikfunktionen |
|
|
Günther schrieb:
| Quote: | 2 wichtige Klassen sind
Klasse Bitmap
Daten
Breite und Höhe eines Bitmaps
Bitmap-Daten selber
Klasse Visual
Ist die Basisklasse aller Fenster, vergleichbar mit CWnd in MFC.
Damit ein flickerfreies Zeichen auf dem Bildschirm möglich ist,
wird zuerst in den Speicher gezeichnet und dann erst das Ergebnis auf den
Bildschirm kopiert.
In Windows verwende ich für die gepufferten Grafikfunktionen ein DC
(device context) im Speicher.
Daten
Zeiger auf das "Vater-Fenster", verkettete Liste mit anderen
"Kind-Fenstern"
Zeiger auf Desktop
DC für die gepufferte Grafikfunktionen
So nun meine Idee
Da die Klasse Visual sowieso in den Puffer zeichnet könnte man sie gleich
von der Klasse Bitmap ableiten.
Vorteil
Vom Betriebssystem benötige ich nur noch die Funktion zum Kopieren
der Bitmaps auf den Bildschirm => viel einfacher portierbar.
Das System wird damit viel einfacher.
Bei Direct-Draw wird sowieso in der Anwendung gezeichnet.
Nachteil
Ich muss alle Grafikfunktionen selber schreiben.
Fragen
Ist die Idee gut oder das ein Design-Fehler?
|
Einfache Frage: Ist ein Bildschirmfenster eine Art Bitmap? Nein? Dann lass
es. Ich nehme an du leitest z.B. auch eine Klasse Button von Visual ab.
Andererseits hast du (eventuell) Filterfunktionen die ein Bitmap spiegeln
oder ein Negativ berechnen. Es macht aber keinen Sinn das Negativ eines
Buttons zu berechnen.
Zur Vereinfachung könntest du allenfalls private oder höchstens protected
von Bitmap ableiten was sich für Betrachter auch als "Visual wird mit Hilfe
von Bitmap implementiert" liest. Aus Performancegründen würde ich aber
Doppelbufferung ohnehin optional machen.
| Quote: | Beispiel Windows MFC
Warum gibt es da eine Fenster-Klasse (CWnd) und einen Context (CDC)?
In Win32 eben WND und DC.
Warum verwendet man dafür nicht eine gemeinsame Klasse?
|
Du kannst auch auf den Drucker oder in Bitmaps oder auf irgendwelche
anderen obskuren Geräte zeichnen. Ein Fenster ist ja nur ein Ziel auf das
man Zeichnen kann. (Vergleichbar mit std::string und std::stringstream. Ein
Stream kann ja auch anderswohin schreiben)
| Quote: | Wie sollte man die Klassen Bitmap, Context und Visual in Relation setzen?
|
Visual und Bitmap haben eine Methode getContext() um Zeichnen zu
ermöglichen. Context hat eine Methode drawBitmap. Ausserdem gibt es eine
Möglichkeit den Inhalt eines Context in ein Bitmap zu bekommen. z.B. für
Screenshots.
Wenn eine Verbesserung der Namen gestattet ist: Ich würde Bitmap eher Image
nennen. Ein Bitmap ist eigentlich systemspezifisch windowsmässig. Statt
Context verwenden die meisten portablen Bibliotheken eher Graphics (von
Java inspiriert) oder Canvas. Zu Visual würde ich eher Window, Widget oder
Component sagen. Sind aber alles nur Vorschläge, v.a. weil es gebräuchliche
Benennungen sind.
| Quote: | In welcher Klasse sollte eine Koordinatentransformation
implementiert werden, zB für Diagramme?
|
Das könntest du in Context machen. Der rechnet sich dann bei jeder
Zeichenfunktion die "richtigen" Koordinaten aus. Alternativ könntest du
auch eine eigene Klasse schreiben die z.B. per operator() Punkte und
Rechtecke umrechnet.
| Quote: | Soll zB die Klasse Diagram von Visual abgeleitet werden oder von Bitmap?
|
Hm. Was genau soll Diagram sein? Eine Komponente die der Benutzer bedienen
kann? Dann würde ich von Visual ableiten. Von Bitmap eher nicht.
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Martin Heibel
Guest
|
| Posted: Mon Sep 01, 2003 7:45 pm Post subject: Re: Design-Fehler? Grafikfunktionen |
|
|
Günther schrieb:
| Quote: | Ich entwickle selber eine neue C++ Bibliothek wie MFC nur besser
Da gehört zwar nicht wirklich viel dazu, dennoch kenne ich wenige |
Entwickler, die so etwas vernünftig hinbekommen würden. Und es ist ein
Haufen Arbeit.
| Quote: | Diese soll auf mehrere Betriebsstemen laufen.
Wenn sie gut ist, ist das kein Problem. |
| Quote: | Klasse Bitmap
Daten
Breite und Höhe eines Bitmaps
Bitmap-Daten selber
Methoden
...
Funktionen zum Laden und Speichern von Bitmaps (.bmp, .gif, ...)
Designfehler: Da solltest Du über Load- und Store-Klassen nachdenken |
(Interfaces + Implementierungen für Dateizugriff). Da kann man später
eigene Varianten schreiben, um Bitmaps z.B. in einer Datenbank zu
speichern.
class BMPStore
{
public:
virtual void store(const Bitmap& bmp) = 0;
virtual Bitmap load() = 0;
};
class BMPFileStore
{
public:
BMPFileStore(const char* fileName);
// ..
};
| Quote: | Zeichenfunktionen (zB Pixel, Linien, Dreiecke,
Funktionen mit Anti-Aliasing, Alpha-Blending, ...)
Gehören in einen Device-Context (sollte man vielleicht anders nennen, da DC |
Windows-spezifisch ist). Es sollte einen Bitmap-DC geben, der alle
Zeichenoperationen auf der Bitmap ausführt.
class DC // Bridge-Pattern
{
public:
class Impl { .. };
protected:
DC(Impl* pImpl);
private:
Impl* _pImpl;
};
class BitmapDC : public DC
{
public:
BitmapDC(int width, int height)
: DC(new BitmapDCImpl(width, height)) {}
BitmapDC(Bitmap& bm)
: DC(new BitmapDCImpl(bm)) {}
Bitmap& getBitmap();
Bitmap getBitmap() const;
private:
class BitmapDCImpl : public DC::Impl { .. };
};
Aber da habe ich Deie Frage von unten vorweg genommen...
| Quote: | Klasse Visual
Ist die Basisklasse aller Fenster, vergleichbar mit CWnd in MFC.
Also ein Rechteckiger Bereich, in den man zeichnen kann? Das ist der DC, |
evtl. könnte ein Visual ein DC mit definierter Clip-Area sein...
| Quote: | Damit ein flickerfreies Zeichen auf dem Bildschirm möglich ist,
wird zuerst in den Speicher gezeichnet und dann erst das Ergebnis auf den
Bildschirm kopiert.
Das braucht man nur bei Animationen. |
| Quote: | In Windows verwende ich für die gepufferten Grafikfunktionen ein DC
(device context) im Speicher.
Ok, aber für das Design nur in so fern relevant, als dass hier klar wird, |
dass der DC verschiedene Implementierungen brauchen wird.
| Quote: |
Daten
Zeiger auf das "Vater-Fenster", verkettete Liste mit anderen
"Kind-Fenstern"
Zeiger auf Desktop
DC für die gepufferte Grafikfunktionen
Methoden
...
Zeichenfunktionen (zB Pixel, Linien, Dreiecke,
Funktionen mit Anti-Aliasing, Alpha-Blending, ...)
Eine Aufgabe <=> eine Klasse. Hier sehe ich viele Aufgaben => viele Klassen. |
| Quote: | So nun meine Idee
Da die Klasse Visual sowieso in den Puffer zeichnet könnte man sie gleich
von der Klasse Bitmap ableiten.
Eine Bitmap ist eine Repräsentation für eine Pixel-Grafik. Dein "Visual" ist |
momentan noch etwas schwammig (was wir gleich korrigieren werden , aber
auf alle Fälle keine Bitmap.
| Quote: | Vorteil
Vom Betriebssystem benötige ich nur noch die Funktion zum Kopieren
der Bitmaps auf den Bildschirm => viel einfacher portierbar.
Das System wird damit viel einfacher.
zu implementieren. Das ist nicht das, worauf es ankommt. Ein System soll |
einfach zu benutzen sein. Inneralb der dadurch gegebenen Grenzen sollte es
möglichst einfach (was auch immer das ist) implementiert werden.
| Quote: | Bei Direct-Draw wird sowieso in der Anwendung gezeichnet.
Nachteil
Ich muss alle Grafikfunktionen selber schreiben.
Du brauchst enorm viel Speicher. Es gibt einen Grund, warum sich der Ansatz, |
alle Fensterinhalte in Bitmaps zu speichern, nicht durchgesetzt hat.
| Quote: | Fragen
Ist die Idee gut oder das ein Design-Fehler?
Letzeres, wobei der Resourcenhunger nicht unbedingt unter "Design" fällt. |
| Quote: | Beispiel Windows MFC
Warum gibt es da eine Fenster-Klasse (CWnd) und einen Context (CDC)?
Ein Fenster ist ein Rechteckiger Ausschnitt auf dem Bildschirm. Diese |
Ausschnitte können verschoben werden, sich überdecken, unsichtbar sein,
etc.
Der DC ist eine Schnittstelle zum zeichnen. Was die Zeichenfunktionen
bewirken, ist unterschiedlich. Es gibt DCs, die nichts tun - die sind sehr
nützlich, um die Größe von Textelementen zu berechnen. Drucken läuft über
einen DC. Die Ausgabe auf ein Fenster erfolgt über einen DC (dessen
Ursprungspunkt relativ zum Fenster ist, egal wo sich dieses befindet.
| Quote: | In Win32 eben WND und DC.
Warum verwendet man dafür nicht eine gemeinsame Klasse?
Weil es zwei verschiedene semantische Konstrukte sind. |
| Quote: | Wie sollte man die Klassen Bitmap, Context und Visual in Relation setzen?
Nenne Fenster ruhig Window, den DC ... Rastport (wer den versteht darf fünf |
Minuten in Nostalgie schwelgen ;^), ok bleiben wir bei DC, der ist so schön
kurz.
class Bitmap // reine Datenklasse
{
public:
int getWidth();
int getHeight();
Color getColor(int x, int y) const;
void setColor(int x, int y);
};
class BitmapDC; // s.o.
class Window
{
public:
int getPosX();
int getPosY();
int getWidth();
int getHeight();
DC getDC();
};
Dazu eine Abstract-Factory, die Plattform-spezifische Klassen erzeugen kann:
class System
{
public:
// Zwei Patterns plus ein Idiom:
// Abstract Factory mit Factory Method als Singleton 8^)
static System& theInstance();
Window createWindow();
};
Detailideen ergeben sich beim Entwerfen, z.B.:
BitmapDC Win32System::createBitmapDC(int w, int h)
{
// Win32-spezifischer Memory-DC-Wrapper
}
BitmapDC XWinSystem::createBitmapDC(int w, int h)
{
return BitmapDC(int w, int h);
}
wer unter Windows Deinen eigenen BitmapDC haben will, kann ihn explizit
erzeugen, aber die Factory liefert eine effizientere Implementierung, wenn
sie kann.
Ich würde generell alle Klassen nach dem Bridge-Pattern und dem
Counted-Body-Idiom entwerfen. Dann kannst Du 1. alle Zugriffe auf die
Factory vor dem Benutzer verstecken (Bridge), 2. die Objekte effizient
kopieren und auf Pointer verzichten (Counted-Body), wie das auch die STL
macht.
| Quote: | In welcher Klasse sollte eine Koordinatentransformation
implementiert werden, zB für Diagramme?
DC sollte ein transformierbares Koordinatensystem haben. Dabei bietet sich |
evtl. das Envelope-Letter-Idiom an, um die Performance zu verbessern (der
Laufzeittyp kennt nur die Transformationen, die gerade benötigt werden) -
nur so eine Idee und unter Windows unnötig, da DCs in Windows so etwas
schon können.
| Quote: | Soll zB die Klasse Diagram von Visual abgeleitet werden oder von Bitmap?
Weder noch. Wenn ein Diagramm ein Diagramm repräsentieren soll, dann sollte |
es nur das tun. Eine andere Klasse zeichnet das Diagramm.
Wenn sich die Aufgaben einer Klasse sinnvoll auf mehrere verteilen lassen,
dann ist es vermutlich auch besser, das zu tun.
| Quote: | Ich möchte ja Diagramme generieren von Kommandozeilentools.
Verstehe ich zwar nicht so ganz, aber egal, klugscheißen kann ich auch so. |
Ich ver,mute jetzt allerdings, dass Du gar keine Bitmaps benötigst, sondern
dass die nur durch die Idee ins Spiel kamen, alles im Speicher zu zeichnen.
| Quote: | Kann mir da jemand gute Tipps geben?
Vermutlich bessere, als Dir lieb ist ;^) |
Schau Dir mal
http://www.bell-labs.com/user/cope/Patterns/C++Idioms/EuroPLoP98.html
an, da findest Du u.a. das Counted-Body- und das Envelope-Letter-Idiom. Nach
der Lektüre bist Du den Ideen, wie ich sie Dir hier angedeutet habe,
vielleicht ein Bisschen näher. Außerdem: lies und verstehe das GOF-Buch (s.
FAQ), sonst fehlt Dir das Rüstzeug für so eine Aufgabe - was nicht heißt,
dass das Verständnis dieses Buchs alles ist, was man dazu braucht.
Gruß,
Martin
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Günther
Guest
|
| Posted: Tue Sep 02, 2003 8:56 am Post subject: Re: Design-Fehler? Grafikfunktionen |
|
|
DANKE für die Antworten!
Ja sind sehr viele Ideen dabei.
Bin halt doch Anfänger!
Muss mich erst mehr einarbeiten.
so, hab das jetzt überarbeitet, neue Bezeichnungen
Pixmap (statt bisher Bitmap)
Daten
Breite
Höhe
Farbwerte der Pixel (RGB und Alpha)
Die Klasse Pixmap enthält auch die Zeichenfunktionen, die
auf ein Pixmap angewendet werden können.
Pixel, Linien, Dreiecke, Vierecke, Polygone, Kreise, Ellipsen
andere Pixmaps
Text
Funktionen mit und ohne Anti-Aliasing und mit und ohne Alpha-Blending.
Laden uns Speichern eines Pixmaps.
(Hier gibt man ein File-Objekt an, die Funktionen erkennen jedes
Grafikformat selbstständig, zumindest .bmp und .gif gibts schon)
zB
pMap->bGet(pFile); bGet steht für Laden, liefert bool
Hab früher mal einen Geschwindigkeitsvergleich durchgeführt,
gemessen in Taktzyklen mit RDTSC.
Pixmap
Zeichnen in ein Pixmap
Windows
Zeichnen in hDC im Speicher erstellt mit CreateCompatibleDC und
CreateCompatibleBitmap
Hardware
AMD 1400
Asus A7V133
512 SDRAM
Geforce 4 64 MB DDRAM
Dargestellt sind die ersten 3 Wiederholungen.
1. 2. 3.
SetPixel(200,150,RED); 600 86 86
; Pixmap
27000 32000 6000
; Windows
SetLine(0,0,200,150,RED); 31000 1400 1350
; Pixmap
350000 33000 17000
; Windows
SetText(200,150,pFont,"Wer ist schneller?",RED); 19000 8300 8100
; Pixmap
63000 13500 11500
; Windows
SetRectF(0,0,200,150,RED); 380000 62000 53700
; Pixmap
46000 32000 9000
; Windows
Für kleine Grafikroutinen (zB Pixel, Line) ist Pixmap viel schneller.
Für Textfunktionen ist Pixmap leicht schneller.
Für große Grafikroutinen (zB Rect) ist Windows viel schneller.
Wie beim X Server möchte ich später von der Anwendung aus auf die
Grafikhardware
zugreifen können (System kann bestimmte IO-Ports für die Anwendung freigeben
und
Grafikspeicher in den virtuellen Adressraum der Anwendung einblenden).
Ich schreibe selber auch ein Betriebssystem, das soll später mal möglich
sein.
Fenster
Bezeichnungen bis jetzt
Visual (Basisklasse aller Fenster)
Window (Fensterrahmen, Fenster mit Titelbalken, System-Buttons, ...)
Ich schreib jetzt aber hier "Window".
Ich möchte zumindest Single-Buffering für Fenster,
Double-Buffering kann ich dann immer noch realisieren.
Single-Buffering deswegen, damit kein Flickern sichtbar ist.
nur einige Beispiele
Animationen,
einzeiligen Texteingabe, der Text sollte nicht flackert beim Editieren
bei einem Editor
Bild mit einem 2. Bild, das drüber liegt in einem Fenster, es darf beim
Neuzeichnen nicht flackern
Diagramm, wenn sich die Quelldaten ändern, der Anwender darf kein
Flackern bemerken
Symbolleiste, wenn man mit der Maus drüber fährt
Button, der Text könnte flackern, wenn man drauf drückt
...
Ist mit Single-Buffering doch viel einfacher oder?
Druckerausgabe
Bevor die Daten an den Drucker geleitet werden, werden sie in einem
Pixmap gerendert.
Man könnte die Drucker-Klasse genau so von Pixmap ableiten.
Warum ich auf Diagramme gekommen bin:
ZB ein Kommandozeilentool, dass Daten im Hintergrund einliest,
ein Diagramm generiert und zB als GIF-Datei abspeichert,
zB für Börsencharts.
Um Single-Buffering zu realisieren muss die Fenster-Klasse einen
Puffer anlegen.
Und da eben die Idee einfach Window von Pixmap abzuleiten.
Daten der Window-Klasse
Desktop
Zeiger auf Vater-Fenster, "Geschwister-Fenster"
Position relativ zum Vater-Fenster
Clipping-Bereich
Flags
Immer wenn dann ins Fenster gezeichnet wird, wird nur ins
enthaltene Pixmap gezeichnet (Single-Buffer)
und am Ende wird diese auf den Bildschirm geblittet
Später vielleicht mal mit Double-Buffering,
bei Vollbild könnte man später auch nur den Zeiger auf den
Bildschirmspeicher auf dieses Pixmap zeigen lassen
(erspart das Blitten)
Nur mit der der DC-Klasse komme ich nicht zurecht.
Warum hat nicht jedes Fenster nur einen DC?
Für den ganzen Client- und Non-Client-Bereich?
Liebe Grüße
Günther
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
Günther
Guest
|
| Posted: Thu Sep 04, 2003 5:04 pm Post subject: Re: Design-Fehler? Grafikfunktionen |
|
|
hi Martin!
Danke sehr für die Antwort!
hab das erst durcharbeiten müssen
Bin halt erst bei der Version 1.0
Ich versuche mal Funktionalität und Geschwindigkeit
zur Laufzeit hinzubekommen.
Auf das andere komme ich sicher noch zurück.
| Quote: | Ich möchte ja Diagramme generieren von Kommandozeilentools.
Verstehe ich zwar nicht so ganz, aber egal, klugscheißen kann ich auch so.
Ich ver,mute jetzt allerdings, dass Du gar keine Bitmaps benötigst,
sondern
dass die nur durch die Idee ins Spiel kamen, alles im Speicher zu
zeichnen. |
Hab versucht mich da bei der Antwort an Rolf besser auszudrücken.
| Quote: | Kann mir da jemand gute Tipps geben?
Vermutlich bessere, als Dir lieb ist ;^)
|
:)
Günther
--
de.comp.lang.iso-c++ - Moderation: mailto:voyager+mod (AT) bud (DOT) prima.de
FAQ: http://www.voyager.prima.de/cpp/ mailto:voyager+send-faq (AT) bud (DOT) prima.de
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
