Adam Luter [mailto:[EMAIL PROTECTED]] wrote:
> Why not use math?
>
> factor = 1024 * 8 / scrp->fbFormat.bitsPerPixel;
> if (mode->HDisplay * mode->VDisplay > scrp->videoRam * factor)
> return MODE_MEM;
>
> This assumes that scrp->fbFormat.bitsPerPixel is a power of two.
>
> Also, really huge monochrome displays are still vunerable. In
> other words, I would also use a 64bit number.
>
> -Gryn
concerning your formula, I am applying
a 24 bpp wide packed pixel format:
1024*8/24 = 341.333
This case might lead to unwanted fractional loss.
Using a special case handling for 24 bpp and similar
would mean that any bit depth could go that way anyways.
But then I do see no need for an "optimized" path at all.
Your version further does not care about
that HDisp and VDisp might multiply to
a value bigger than 2 GB and therfore getting
negatvie if input values were choosen evil minded.
I considered such a division approach myself,
but in the end this is only save if you
can ensure limited ranges for all numbers.
But we should not build up further limits
since there were already two suggestions
that do not need that at all
One thing to discuss is the likeliness for
64 bit math support versus the support for
integer division on the target platform.
-Alex.
>
> On Tue, Nov 05, 2002 at 01:09:14AM +0100, Alexander Stohr wrote:
> > Hmm, looks like a limitation of the inital coders knowledge.
> > Nothing to worry about in an OpenSource project where lots
> > of coding youngsters did take part in.
> >
> > The below coding:
> >
> > if (mode->HDisplay * mode->VDisplay * scrp->fbFormat.bitsPerPixel
> > > scrp->videoRam * (1024 * 8))
> > return MODE_MEM;
> _______________________________________________
> Xpert mailing list
> [EMAIL PROTECTED]
> http://XFree86.Org/mailman/listinfo/xpert
>
>
