Says who? Look, the problem with gfx all over is that it never documented which structures are internal, and which are not. Is a struct ViewPort an internal structure?
Hard to say. It is documented. Should it be documented? Probably not.
From developer point of view ViewPort is not an internal structure. You just fill some data and pass pointer to MakeVPort(). Internally the OS could convert data to its own private, internal format. We know that the OS dont do that but it could have been designed to work like that...
Some parts work like this. For example to open window you can create NewWindow structure. Internally Intuition is not linking this structure to its private data but new structure, Window, is created instead. Unfortunately this structure is returned to the caller... but you get the idea. The struct NewWindow describes what you want and Intuition does its best to satisfy your request.
Really? So for example, what is the difference between the APen, which must be set with SetAPen() or it does not function correctly, and the WriteMask, which is poked into the structure but still works? Does it work by accident? By intention?
The difference between the APen and the WriteMask is an implementation detail: The APen forces a recomputation of the MinTerms, the WriteMask does not. But that's simply "how gfx works internally", and it's really not spelled out that explicitly. Somehow, "you have to know".
I know that SetAPen() calculates those silly minterms. But from implementation point of view there is no need to calculate this data in SetAPen(). Minterms could be calculated in drawing operations and results could be cached to some
other private data structure.
In RTG systems SetAPen() is even less useful because there private minterms are not used anymore. However, at the time when SetAPen() is called it can't know this and it has to recalculate minterms just in case. If minterms were checked in RectFill()/Text()/whatever you could skip this minterm calculation when it is not needed by target bitmap.
It really boils down to that: Gfx is a big piece of junk, it is exactly "how not to write software", namely not defining proper interfaces. Gfx leaves it pretty much unclear which part of it is an interface, and what is internal, and where which part stops.
I agree.
From a clean API design POV, this structure should be undocumented, and you should use getters and setters. But gfx does not have an "API design". It is quickly hacked together, and it shows.
It depends. In Windows API you are passing loads of parameters through structures. They are just parameter containers, not internal OS structures that would be passed through to OS. RastPort should be just like this: a paremeter container.
So for example, why would graphics card hardware have to read the write mask from the rastport? It could also store it somewhere else, in some other form. SetWriteMask() could very well be patched over, performing internal adjustments of whatever the graphics card software has to do.
It can do that, even when setting write mask directly to rastport. For example when Text() is called the system could collect relevant parameters from RastPort to its own internal private structure and execute render function asynchronously on the target hardware.
