From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NhMcB-0004IK-7I for mharc-grub-devel@gnu.org; Tue, 16 Feb 2010 07:33:19 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NhMc8-0004Ga-BG for grub-devel@gnu.org; Tue, 16 Feb 2010 07:33:16 -0500 Received: from [140.186.70.92] (port=47069 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NhMc6-0004GS-IU for grub-devel@gnu.org; Tue, 16 Feb 2010 07:33:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NhMc5-0003nq-8x for grub-devel@gnu.org; Tue, 16 Feb 2010 07:33:14 -0500 Received: from mail-fx0-f215.google.com ([209.85.220.215]:61248) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NhMc4-0003nl-SX for grub-devel@gnu.org; Tue, 16 Feb 2010 07:33:13 -0500 Received: by fxm7 with SMTP id 7so6240887fxm.8 for ; Tue, 16 Feb 2010 04:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type; bh=el+bTIcJAprPFez8dZ5KW0MU69vUBgY0leyJ8GxUW5I=; b=jFCOU8kgEBR2BueUQ0FwUvYzb/NxdvttXS3pk9ktH38HqVwUYq4tANvmf1ZnS9OYHp X21f+OGkPTTFKRIJJELe1Rt5z1Ly2Nb1c08CN0l8k6frAtLxRlZtqKl1mEwUW4e88Xwy cqH6xqFDcwpFtF1CjlDFyqvOlCJmtT0xvElCo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; b=Gz/q7mki18DGBg+XVokmRwilJB555dKx/PfIPgA7XUa363WoDcWFOwjUCcEOdxsNwL DYl/04CvcjAzVqeaXzkLmWJ6wpGi5wpCq/2pnXKpH2m/k6ZBK4hKgm/4JNcBUNtmUdBz Ijy0qIK37k6Kq2+IQiVeiruwYGVdnIu/cuagQ= Received: by 10.87.20.13 with SMTP id x13mr11372482fgi.67.1266323587774; Tue, 16 Feb 2010 04:33:07 -0800 (PST) Received: from debian.bg45.phnet ([81.62.76.105]) by mx.google.com with ESMTPS id d8sm16446106fga.8.2010.02.16.04.33.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 16 Feb 2010 04:33:05 -0800 (PST) Message-ID: <4B7A9075.9050400@gmail.com> Date: Tue, 16 Feb 2010 13:32:53 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109) MIME-Version: 1.0 To: The development of GNU GRUB References: <4B736F82.7010005@gmail.com> <4B742B70.3080303@gmail.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigCD476ED0A114E138A7B412D9" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [RFC] Framebuffer rotation patch X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2010 12:33:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCD476ED0A114E138A7B412D9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michal Suchanek wrote: > 2010/2/11 Vladimir '=CF=86-coder/phcoder' Serbinenko : > =20 >> Michal Suchanek wrote: >> =20 >>> 2010/2/11 Vladimir '=CF=86-coder/phcoder' Serbinenko : >>> >>> =20 >>>> Michal Suchanek wrote: >>>> >>>> =20 >>>>> Hello >>>>> >>>>> Sending a preliminary framebuffer rotation patch. >>>>> >>>>> You can use videotest to see 4 tiles rotated from the same bitmap d= ata. >>>>> >>>>> >>>>> >>>>> =20 >>>> +char leaf_data[] =3D { 0x00, 0x0f, 0xe0, 0x00, >>>> + 0x00, 0x7f, 0xfc, 0x00, >>>> + 0x01, 0xff, 0xff, 0x00, >>>> + 0x03, 0xff, 0xff, 0x80, >>>> This is a blob. Could it be generated automatically at build time? >>>> >>>> =20 >>> How less of a blob it would be if it was included as a bitmap? >>> >>> >>> =20 >> It's not easily editable in current form. >> =20 >>> This is just a shape used for the video tests. >>> >>> There are some X tools for working with bitmaps/pixmaps which could >>> generate this from a viewable file but they are usually not available= >>> on Windows and other non-X platforms AFAIK. >>> >>> >>> =20 >> Using XBM is fine (it's easily editable in either gimp or emacs) and y= ou >> should be able to >> #include "leaf1.xbm" >> =20 > > That would work if XBM and grub did not have opposite bit order. The > bytes are ordered the same but the bits are reversed. > > =20 >>>> Could you split addition of videotests from the rest of the patch? >>>> =20 > > Yes, there should be no problem with that. > > =20 >>>> - unsigned int x; >>>> - unsigned int y; >>>> - unsigned int width; >>>> - unsigned int height; >>>> + int x; >>>> + int y; >>>> + int width; >>>> + int height; >>>> Why do you need negative values? >>>> >>>> =20 >>> I don't need the negative values everywhere but this change was to >>> align the typing so that casts are not required. >>> >>> >>> =20 >> Perhaps few casts together with appropiate checks when casting is bett= er >> than potentially exposing the whole code to the values it's not intend= ed >> for. >> =20 > > How is it exposed to more unwanted values than now? > It uses the variables only to store the viewport dimensions and at > most adds a border around it. The unsigned integer is able to > represent values outside of the viewport as much as signed integers > are, only signed integer can represent values outside of viewport in > both directions. The unwanted values (if erroneously calculated which > does not seem to be the case here) are clipped by the viewport > clipping in video_fb. > > On the other hand, there would be more than a few casts as the > variables are used multiple times and the interface now uses signed > integers. > > =20 >>>> +/* Supported operations are simple and easy to understand. >>>> + * MIRROR | swap image across (around) the vertical axis >>>> + * FLIP - swap image across the horizontal axis - upside down >>>> + * SWAP / swap image across the x=3Dy axis - swap the x and y c= oordinates >>>> It's just a D_8 group. Could you add a comment to functions what the= y do >>>> in group theoretical sense? It would make the code easier to follow = and >>>> >>>> =20 >>> Obviously it is a group, >>> =20 >>> any set of transforms closed on composition is. >>> >>> >>> =20 >> Not true. Consider an example of empty set: it has no identity element= =2E >> Less trivial counter-example: set of transformations: (x,y)->(kx,ky), >> 0> with <=3D1 you will have an identity element but no other element is >> invertible. >> =20 > > It depends on your exact definition of group which somewhat varies but > it is true that most definitions at least require the set to be > non-empty. > > =20 >>> If you have clearer explanation or more efficient code please share. >>> >>> >>> =20 >> I was thinking of using 2 generators instead of 3: >> 1) standard generators: s=3Drot90 or rot270, t=3Dany reflection. Then = all >> elements are s^k or s^k*t. It makes computation of composition easier.= >> Rules on generators are: >> s^n=3Dt^2=3D1 >> tst=3Ds^{-1} >> 2) or using 2 reflections. E.g. u=3D| and v=3D/. You already figured h= ow to >> generate with u=3D|, v=3D/, w=3D- >> But w=3Duvuv >> Then rules of computation are: >> u^2=3Dv^2=3D(uv)^4=3D1 >> =20 > > This might be mathematically optimal but how that maps to actual effici= ent code? > > In my view the v (and s) operations are expensive so I want to avoid > them if possible. > =20 I actualy though of using preprocessor magic to make 8 blitting functions= =2E I don't insist on any particular group representation, just want to be sure you take it into account. > This requires that both u and w be in the chosen set of generators > because otherwise use of v or s twice is required to get one from the > other. Using (u or w) and v as the two basic operations additionally > requires composing generators in non-fixed order to get all the 8 > possible combinations. > > The other reason for having 3 generators is clear and efficient > reperesentation of the 8 possible transformations. They are > represented as bits in the bitmap where each bit specifies if the > particular basic transform is included or not but they are always > applied in fixed order and at most once. > > Compare this to your representation of s^k,s^k*t where k is 0..3. > Depending on representation the composition and inversion rules might > still be somewhat non-trivial in actual code, using two reflections > which require multiple applications of the two generators in > particular order would lead to even more "interesting" code. > > =20 You don't have to use same representation through whole code >>>> +static inline long >>>> +grub_min (long x, long y) >>>> +{ >>>> + if (x > y) >>>> + return y; >>>> + else >>>> + return x; >>>> +} >>>> + >>>> Same here >>>> + >>>> + int transform; >>>> I would prefer an enum >>>> >>>> =20 >>> This is a bit field. How does it transform into an enum? >>> >>> =20 >> enum my_bitfield >> { >> MY_BITFIELD_NONE=3D0, >> MY_BITFIELD_BIT0 =3D 1 << 0, >> MY_BITFIELD_BIT1 =3D 1 << 1, >> MY_BITFIELD_BIT2 =3D 1 << 2 >> }; >> =20 > > The whole point of a bitfield is to have values like > MY_BITFIELD_1_AND_2 =3D MY_BITFIELD_BIT1 | MY_BITFIELD_BIT2 which enum > does not allow. > =20 enum allows it just fine > Thanks > > Michal > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > =20 --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enigCD476ED0A114E138A7B412D9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iF4EAREKAAYFAkt6kHsACgkQNak7dOguQgmYrgEAjn5A1jnoHSufjdHw4K6kuEGb 0pCq7d1dGsRchN4kXOABAJCtwbcRtgZpXoEiwuuEtNKt5AJCWUAENj7bfYVfYMV1 =hUES -----END PGP SIGNATURE----- --------------enigCD476ED0A114E138A7B412D9--