linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Antonino A. Daplas" <adaplas@hotpop.com>
To: David Eger <eger@havoc.gtf.org>, Andrew Morton <akpm@osdl.org>
Cc: linux-fbdev-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fb accel capabilities (resend against 2.6.7-rc2)
Date: Thu, 3 Jun 2004 23:07:13 +0800	[thread overview]
Message-ID: <200406032307.13121.adaplas@hotpop.com> (raw)
In-Reply-To: <20040603023653.GA20951@havoc.gtf.org>

On Thursday 03 June 2004 10:36, David Eger wrote:

I haven't tested the patch, but here's a few comments:

So, 

1. SCROLL_ACCEL = no panning + copyarea;
2. SCROLL_REDRAW = no panning + imageblit;
3. SCROLL_PAN/SCROLL_WRAP = pan/wrap + copyarea;

Are these correct?

Assuming the above is correct, then the logic in update_scrollmode() may not 
be optimal.

>  static __inline__ void updatescrollmode(struct display *p, struct fb_info
> *info, struct vc_data *vc) {
> -	int m;
> +	int cap = info->flags;
>
> -	if (p->scrollmode & __SCROLL_YFIXED)
> -		return;
> -	if (divides(info->fix.ywrapstep, vc->vc_font.height) &&
> -	    divides(vc->vc_font.height, info->var.yres_virtual))
> -		m = __SCROLL_YWRAP;
> -	else if (divides(info->fix.ypanstep, vc->vc_font.height) &&
> +	if ((cap & FBINFO_HWACCEL_COPYAREA) && !(cap & FBINFO_HWACCEL_DISABLED))
> +		p->scrollmode = SCROLL_ACCEL;

We should also check if the hardware is capable of panning/wrapping.  If it 
is, then the scrolling mode should be SCROLL_PAN/WRAP. An accelerated drawing 
function combined with panning/wrapping is extremely fast.

> +	else if ((cap & FBINFO_HWACCEL_YWRAP) &&
> +		 divides(info->fix.ywrapstep, vc->vc_font.height) &&
> +		 divides(vc->vc_font.height, info->var.yres_virtual))
> +		p->scrollmode = SCROLL_WRAP;
> +	else if ((cap & FBINFO_HWACCEL_YPAN) &&
> +		 divides(info->fix.ypanstep, vc->vc_font.height) &&

In the above case, we should also check if accelerated copyarea is availble or 
if fb reading is fast.  Because if fb reading is slow and accel copyarea is 
not available,  the resulting scrolling action will not be smooth. In this 
case, SCROLL_REDRAW may be a better scrolling mode even if it's slower than 
SCROLL_PAN/WRAP.

>  		 info->var.yres_virtual >= info->var.yres + vc->vc_font.height)
> -		m = __SCROLL_YPAN;
> -	else if (p->scrollmode & __SCROLL_YNOMOVE)
> -		m = __SCROLL_YREDRAW;
> +		p->scrollmode = SCROLL_PAN;
> +	else if (cap & FBINFO_READS_FAST)
> +		/* okay, we'll use software version of accel funcs... */
> +		p->scrollmode = SCROLL_ACCEL;

This is similar with the above.  If panning/wrapping is available and fb 
reading is very fast, then SCROLL_PAN/WRAP is probably preferrable than just 
SCROLL_ACCEL.

>  	else
> -		m = __SCROLL_YMOVE;
> -	p->scrollmode = (p->scrollmode & ~__SCROLL_YMASK) | m;
> +		p->scrollmode = SCROLL_REDRAW;

Ditto.

Personally, the pseudocode below might be better.

If (pan/wrap is available) {
	if (fb reading is fast || accel copyarea is available)
		SCROLL_PAN/WRAP;	
	else 
		SCROLL_REDRAW; /* since SCROLL_PAN/WRAP_REDRAW not available */
} else {
	if (fb_reading is fast || accel copyarea is available)
		SCROLL_ACCEL;
	else
		SCROLL_REDRAW;
}
 
Tony




-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504

  reply	other threads:[~2004-06-03 15:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-03  2:36 [PATCH] fb accel capabilities (resend against 2.6.7-rc2) David Eger
2004-06-03 15:07 ` Antonino A. Daplas [this message]
2004-06-03 18:01   ` [Linux-fbdev-devel] " David Eger
2004-06-03 20:46     ` Thomas Winischhofer
2004-06-04  1:26       ` David Eger
2004-06-04  0:06     ` Antonino A. Daplas
2004-06-04  2:24   ` [PATCH] fbcon: prefer pan when available David Eger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200406032307.13121.adaplas@hotpop.com \
    --to=adaplas@hotpop.com \
    --cc=adaplas@pol.net \
    --cc=akpm@osdl.org \
    --cc=eger@havoc.gtf.org \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).