| [View Project][View Threads]| Title: | 2D structured art datatype superclass |  | Synopsis:
A drawing.datatype superclass for 2D structured artwork, and an IFF DR2D subclass. |
| chris | Implementation thoughts | 20090521 00:20 |  | The primary thing to think about here is how programs should get the data out of the superclass, and how the subclasses get the data in. The best method I can come up with is a repeat calling of DDTM_READPOLY/DDTM_WRITEPOLY.
This would be a structure (to be defined*) which would contain one attribute and polygon definition, similar to a combined ATTR+OPLY/CPLY/STXT (AFAIK this at least fits how both DR2D and SVG are structured). The superclass would hold the data internally in an Exec linked list. DDTM_READPOLY would probably require the polygon number to be specified, or some way of resetting the counter (I'm not too bothered about READPOLY at this stage as it is 3rd party apps, rather than Multiview, which need to get at this data)
Other attributes would be set by getting a pointer to that structure - there could be a structure for dash patterns (DASH) or fonts (FONS). Some of this may be mergeable into the linked list structure above.
* this needs to be defined in such a way to make it expandable without breaking subclasses or applications
These methods need to be implemented at a minimum I think:
OM_NEW, OM_DISPOSE, OM_GET, OM_SET, OM_UPDATE, GM_LAYOUT, GM_RENDER, DTM_FRAMEBOX, DDTM_WRITEPOLY (and any other superclass-specifics)
For GM_RENDER we need to get the dimensions of the area it is to be rendered into (I think this is what DTM_FRAMEBOX is for) for scaling purposes, and probably draw the picture using Cairo - as graphics.library doesn't have any functions for drawing bezier curves, and Cairo is the only other OS-included option without writing a custom bezier curve routine.
Frederik's OS4 port of Stefan Ruppert's binary.datatype looks like a reasonable template to build this on top of.
Is it possible to test a superclass without concurrently also writing a subclass?
| | |
|
Navigate: 1-5
| salass00 | Re: Implementation thoughts | 20090526 19:47 |  | @chris
The CMAP chunk is perfectly capable of storing an entire 32-bit palette if absolutely necessary, or could be extended to RGBA without breaking existing software)
|
|
This seems neither possible nor practical.
Reasons:
- CMAP chunk can only contain 24-bit RGB data (num colors = size of chunk / 3)
- CMAP must be smaller than 2^32 bytes (4 GB)
- An entire 32-bit ARGB palette would need 4*2^32 bytes = 16 GB!
- An entire 24-bit RGB palette would need 3*2^24 bytes = 48 MB!
Either assume that color data is ARGB if there is no CMAP or maybe add another chunk ("CSP ") that would specify the color space to use (CLUT or ARGB) and would default to CLUT if omitted.
| | |
|
| salass00 | Re: Implementation thoughts | 20090526 19:57 | | @chris
For GM_RENDER we need to get the dimensions of the area it is to be rendered into (I think this is what DTM_FRAMEBOX is for) for scaling purposes, and probably draw the picture using Cairo - as graphics.library doesn't have any functions for drawing bezier curves, and Cairo is the only other OS-included option without writing a custom bezier curve routine.
|
|
I agree about using Cairo instead of graphics.library also because AFAIK with Cairo you also get antialiasing which is more or less needed for curves and circles to look any good (just look at piechart.gadget f.e.). | | |
|
| chris | Re: Implementation thoughts | 20090526 21:50 | | @salass00
I did realise afterwards that changing CMAP to RGBA actually wouldn't work - don't know what I was thinking!
Perhaps an AMAP which just specifies the alpha levels will be good for compatibility. When I was test-writing the DR2D saver of svg2dr2d I found that omitting CMAP, DASH etc tended to make the reading routines of popular software crash.
| | |
|
| chris | Re: Implementation thoughts | 20091115 13:06 | | @chris
superclass global
DRHD
superclass node
ATTR
CPLY } add point, add curve, move to,
OPLY } close path
STXT
subclass internal
CMAP
FONS
DASH
AROW
FILL
LAYR
ignore
PPRF
BBOX
XTRN
GRUP
support later
VBM - via picture.datatype
TPTH
(fonts)
OFNT
OFHD
KERN
CHDF | | |
|
| chris | Re: Implementation thoughts | 20091115 13:26 | | Trying to make this as simple for the superclass and subclasses as possible.
DDTA_DrawingHeader gives the subclass a DRHD structure.
Dashes, colours etc are held locally by the subclass and passed as part of an extended ATTR.
New method: DDTM_ADDATTR DDTM_Dummy + 1
structure is effectively an ATTR chunk but colours, dashes etc are in-line (colours are ARGB)
New method: DDTM_ADDPOLY DDTM_Dummy + 2
Proposed structure:
struct ddtChunk
{
ULONG MethodID;
ULONG ddtc_ChunkType; /* see below */
float ddtc_PosX;
float ddtc_PosY;
float ddtc_PosX2; /* DDTC_BEZIER only */
float ddtc_PosY2; /* DDTC_BEZIER only */
};
/* Chunk Types */
#define DDTC_BEZIER 0x1 /* bezier curve */
#define DDTC_MOVETO 0x2
#define DDTC_POINT 0x0 /* normal polygon point */
#define DDTC_CLOSE 0x4 /* last point - close polygon (CPLY) */
Superclass adds a node to the list for both of these methods.
Software reading via datatype.library will read through drawing.datatype's list sequentially using another method (DDTM_GETCHUNK) | | |
|
Navigate: 1-5
|
|
