On 3/13/02 at 10:06 PM Marcel Kilgus wrote: > Now that you mention stippling, it is my opinion that when having > 16 bit colours there is no need for stipples anymore (I mention this > because I've heard that Tony invested quite a lot of thinking about > how to get stipples in). What is the general opinion about that?
My opinion would be that it would be nice to have a thing that could calculate a 16BPP (or 15BPP) stipple of sorts out of a 24BPP definition so applications can use this but I don't think it really needs to be implemented as part of the PE (not to mention that it seems to be very difficult). I can hardly see a need for a user interface to use more than 32/64k colors. >>> Hmm, on the one hand there's already the normal palette mode which is >>> well defined and I think it's unlikely that the user changes it. >> Which one would that be? i hope we are not talking about the 256 color >> system palette imposed by the PC? Or am i missing something? >No, I mean the palette SMSQ uses on palette calls. It's predefined >with certain colours (list is at the end of GD2 docs) and I think that >most people will leave it this way. Ah... I see. >> IMHO this might prove to be a serious problem in the future given >> the philosophy of WMAN - simply because the save areas increase >> 8-fold, the consequence of which is the speed of their manipulation >> decreases by the same factor. > I know... > Most manipulations aren't really much slower than their 2bit > equivalent, the calculations are a lot simpler. The problem comes when > big chunks of memory need to be altered That's precisely what I meant. Scrolling must be the biggest issue, but in an environment with background update, this is an issue one cannot really solve (just thinking in advance here). > Finally in the end there should be a standard graphics library thing > which can be consulted for all things involving graphics manipulation, > like colour conversions so that not every single application has to > implement that stuff etc. And those routines could be accelerated, > too. All I can say is: AMEN! >> It really undermines one of it's best qualities: speed/simplicity. >> Just don't get me wrong, I don't think this is something that needs >> immediate attention... > Well, I really hope that people make their applications more > colourful. I do encourage to brush up older applications Agreed - the question being, HOW colorful do they need to be? Certainly not 4 colors. 16 would already be more like it, 256 is already pushing it a bit. Mind you, the idea is to have whatever number of colors chosen from a 15BPP palette, so essentially, they get more colorfull eve if they only use 4 colors. > e.g. Jochen is currently trying to get the QPAC2 source code so that > we/I can extend it. This is very important in my eyes). Agreed. > But I need to know how much save area to allocate beforehand. What > happens if an application is considered 2bit only and all of a sudden > it issues an iow.papt (true colour paper trap) call with some exotic > colour? The result would be the use of the aforementioned thing that does color conversion, and the result of that would be a 2-bit stipple definition. See below. >> What I meant is that hardware capable of doing >4 colors can still show >> the 4 colors and given proper screen drivers, 'lesser mode' applications >> will still work without modification, just like they do now with the new >> drivers. > I'm not completely sure whether I get this right, you're proposing > some sort of the old MODE4-MODE8 switch? Well, for one I don't like > that and hardware like the Qx0 do make a problem there because the 4 > colour mode is restricted to the poor 512x256 resolution. No, the 'mode switch' would really only establish what kind of save area te job needs and change the way a color definition as given is interpreted by the driver - It would be a 'property' linked with the main application window. There would also be a 'system variable' where the default for this would be set if the job does not provide a value. The idea is precisely not to have the jobs know they are running in a particular mode unless they ask for it speciffically. This is a big plus because even with your extensions to the PE, you will hardly tend to use a large number of colors. If you define the system default to be 16 colors, and use a real screen at 16BPP, programs that don't specify a mode will use 16 colors - if so desired out of a palette of whatever number of colors the actual hardware provides. The color conversion routines take care that when a job specifies a color, you get something close to it on the screen. If your actual screen is not set for many colors or it simply can't do it, you gat a stipple. The idea is to remove the need for programs to cater for multiple screen modes which certainly does not help things right now. The system palette is a huge help with this. Now, don't get me wrong, I fully understand that this is a VERY tall order. And it's not something to do _right_now_ but something to think about for the future. At this point, you only make recomendations :-) >> Apps writen for mode 4 work in 32/33 simply because the drivers >> translate for them. > I wouldn't call it "translate". The applications issue a "I want a red > paper" call and the screen driver handles this in a way suitable for > the graphics mode. There isn't really any 2bpp->16bpp translation > involved. Well, that's exactly what I meant - the driver handles it, whatever it is. The application doesn't need to know - and that's a GOOD thing!!! >> Francois Lanciault wrote: >> Could you please, PLEASE add GD2 support to the Aurora ? It would >> add a lot of users to High Color migration. I know it is probably >> not easy but I'm sure Nasta will help !! > Well, I am considering it. But I also expect this to be many many > many hours of work. I don't even have the hardware for it. Someone mentioned that the QXL drivers have a 256 color mode? If so, that could be used as a template. It would certainly be a very welcome developement! Nasta
