From owner-freebsd-hackers@FreeBSD.ORG Fri Feb 22 21:59:54 2008 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 65BB216A403 for ; Fri, 22 Feb 2008 21:59:54 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.70]) by mx1.freebsd.org (Postfix) with ESMTP id 5BABA13C442 for ; Fri, 22 Feb 2008 21:59:54 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp005-s [10.150.69.68]) by smtpoutm.mac.com (Xserve/smtpout007/MantshX 4.0) with ESMTP id m1MLxr08001839; Fri, 22 Feb 2008 13:59:53 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp005/MantshX 4.0) with ESMTP id m1MLxpjS018563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 22 Feb 2008 13:59:52 -0800 (PST) Message-Id: <073CCEB2-3124-4631-A034-6A23544A6177@mac.com> From: Marcel Moolenaar To: Oliver Fromme In-Reply-To: <200802222039.m1MKduRf027996@lurza.secnetix.de> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 22 Feb 2008 13:59:50 -0800 References: <200802222039.m1MKduRf027996@lurza.secnetix.de> X-Mailer: Apple Mail (2.919.2) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: /boot/loader graphics support & extensibility X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 21:59:54 -0000 On Feb 22, 2008, at 12:39 PM, Oliver Fromme wrote: >> At the same time the VGA driver is abstracted from any >> high-level details, like fonts or character sets. This >> means that it's easy to write an accelerated driver for >> some graphics hardware. You simply implement mode >> setting and bitblt and you're good to go. > > Yes, that'll work well for putting characters on the > screen. But I don't think it is suitable for generic > graphics operations, even (and especially) for drawing > single pixels. True. What do you envision? How generic do you think we should make it? For me the difference between an abstraction solely based on bitblt and an abstraction that includes a couple more primitives is minimal. The key aspect is that we should not have to duplicate 1000 lines of code, of which less than 10% deals with the hardware. This, for example, is a problem with syscons and the keyboard- and video switch interfaces. The keyboard switch interface alone has 18 functions???? That's a bad abstraction, nothing else. >>> You bitblt the 4 edges. I didn't say it was the most >> performance optimal thing to do. I only said that it >> can be abstracted that way. > > I'm sorry, I should have been clearer, that gfx_rect() > function draws a filled rectangle. I see. In that case it's a single bitblt operation :-) > For the loader, I plan to support bitmaps in an upwards- > compatible way. E.g. you should be able to use a 4bit > PCX file in 8bit and 24bit modes (but not the other way > round). That's an excellent plan. >> But I need to keep all those future enhancements in > mind, even if they're not first priority, or otherwise > it might become more difficult later on to add those > features. I also want to avoid breaking the syntax of > FICL words once they're established. That's why I > have to think about all that now. Yes. >> I think performance is not a concern. >> Once you have the basic functionality, you'll also have a >> wishlist of things you want to do better; performance one >> of them in all likelyhood. > > Performance isn't my highest priority, but not the lowest > either. I try to do things in a way so that they're not > horribly inefficient. At the very least I try to do it > in a way so that they can be made more efficient easily. Agreed. Be aware of making the mistake to separate and distinguish between variations of a single operation at too high a level. For example: it's much more costly to separate vertical line drawing from horizontal line drawing from any other kind of line drawing at the MI layer, than it is at the hardware level. The hardware level needs to check the parameters anyway and unless there's hardware acceleration it'll perform separate code paths most of the time. The upshot of a single line drawing primitive is that you don't have to worry about the coordinates and which API function you must call. This is important when the coordinates are parameters to some function and you'll find yourself coding like: if (isvertical(x1,y1,x2,y2)) drawline_vertical(...) elif (ishorizontal(x1,y1,x2,y2)) drawline_horizontal(...) else drawline_generic(...) With hardware acceleration you may not have to care at all and when you need to draw the line in software, you need to test the coordinates anyway and split the work based on angle even. In that case you also split horizontal and vertical. Anyway: that's enough out of me. I think what you're doing is great and I can't wait to see it realized... -- Marcel Moolenaar xcllnt@mac.com