This is the mail archive of the xconq7@sources.redhat.com mailing list for the Xconq project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Reduced Image Quality for 32x32 Pixel Units


mskala@ansuz.sooke.bc.ca wrote:

Another possible way of dealing with it might be to change the APIs so
that the interface can request from the kernel "Give me an image somewhere
in this range of sizes, and try to avoid scaling if possible."

This is what I was looking into earlier today in response to Elijah's bug report. It seems that 'best_image' could be modified to take "int w1, int h1, int w2, int h2" instead of "int w, int h". Probably we would want to change its name to 'best_image_in_range' or something like that. For backwards compatibility, we then make a 'best_image' function which calls 'best_image_in_range' with w1 == w2 and h1 == h2. I started to look at the logic involved, but got distracted by other things. I could probably make the changes, but I would be much more comfortable if you did, Matthew.


I'm starting to get a rough idea of what API changes need to be made.
Maybe it'd be appropriate to do the CVS-branch thing,

I'll try to get around to setting up a branch in CVS tomorrow. As long as the yellow pixels problem and low res pixel color problems are fixed before 7.5.0, I don't really care how long development goes on in a special branch.


FWIW, I actually like the blocky look of the scaled images, but I'm
guessing I'm in the minority there.

I have mixed feelings about it. But, I have an old monitor with a not-so-good dot pitch, so the way I see things on screen is generally not as clearly as people using sharper monitors.


Eric


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]