Optimizes BlackWhiteRaster. #107
Conversation
|
Clean version of #102. WhiteBlackRaster overtly corrects for incongruity with the meaning of "black". Delegates to the cleaner version of the class as part of piecemeal approach. |
|
Trying to use the latest code for the driver without changing things I realized the BlackWhiteRaster needed to be able to return the RasterElement underlying it. The RasterBuilder function is great but requires that class type. And I documented the functions you asked about. Rebasing this only needs to drop BlackWhiteRaster in the branch to replace BlackWhiteRaster. Since the other class already went through. |
|
Do we need to test this with all existing drivers or should it be transparent to the outside? |
|
The BlackWhiteRaster had entirely private internal structures. All the functions in here return the same data they returned in the old version. I simply delegated to a different class that does the same things in a more robust manner, thus being correct to replace the GreyRaster and AdapterBufferImage classes. So it should be a modular change. In addition, BlackWhiteRaster isn't actually directly called by any of the drivers. Those use the helper functions in the RasterPart code. These elements of reading and writing in the object are covered in the test functions for BlackWhiteRaster and RasterPart. The intent was to replace BlackWhiteRaster with RasterElement but that was too severe, so this merely delegates to the more robust code. Which will speed things a bit, but should categorically not break anything. |
No description provided.