From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1V1AfL-0002FJ-ED for mharc-grub-devel@gnu.org; Mon, 22 Jul 2013 03:36:19 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41025) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1AfI-0002Ej-Fo for grub-devel@gnu.org; Mon, 22 Jul 2013 03:36:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1AfH-0008T1-A7 for grub-devel@gnu.org; Mon, 22 Jul 2013 03:36:16 -0400 Received: from collab.rosalab.ru ([195.19.76.181]:44095) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1AfG-0008Sh-Tu for grub-devel@gnu.org; Mon, 22 Jul 2013 03:36:15 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by collab.rosalab.ru (Postfix) with ESMTP id 4400B78E8003; Mon, 22 Jul 2013 11:36:12 +0400 (MSK) X-Virus-Scanned: amavisd-new at rosalab.ru Received: from collab.rosalab.ru ([127.0.0.1]) by localhost (collab.rosalab.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MD7+lDNp-o73; Mon, 22 Jul 2013 11:36:11 +0400 (MSK) Received: from icedphoenix.localnet (unknown [217.199.216.178]) by collab.rosalab.ru (Postfix) with ESMTPSA id CF36B78E8002; Mon, 22 Jul 2013 11:36:11 +0400 (MSK) From: Vladimir Testov To: grub-devel@gnu.org Subject: Re: [PATCH] grub-core/gfxmenu/widget-box.c - bugfix: incorrect drawing in cases of NULL center slice Date: Mon, 22 Jul 2013 11:36:11 +0400 Message-ID: <3213544.R7GVZuqFGs@icedphoenix> User-Agent: KMail/4.10.4 (Linux/3.8.0-26-generic; KDE/4.10.4; x86_64; ; ) In-Reply-To: <20130720181804.459d80fd@opensuse.site> References: <3516310.x8V9U5xGG7@icedphoenix> <20130720181804.459d80fd@opensuse.site> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 195.19.76.181 Cc: Andrey Borzenkov X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 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: Mon, 22 Jul 2013 07:36:17 -0000 On Saturday, July 20, 2013 06:18:04 PM Andrey Borzenkov wrote: > =D0=92 Wed, 17 Jul 2013 21:55:58 +0400 >=20 > Vladimir Testov =D0=BF=D0=B8=D1=88=D0=B5= =D1=82: > > See screenshots included. > >=20 > > If the center slice is NULL then west or north slice is also NULL >=20 > Why? As far as I can tell code is supposed to scale all parts of > bitmap. What triggers this problem? Code is supposed to scale all parts of a bitmap. Yes. It does actually. But if the bitmap's size is zero then scaled bitmap w= on't be=20 created. There are two arrays of bitmaps: original and scaled. Some of the scale= d=20 bitmaps can be non-existent. And for correct drawing of the styled box = with=20 some zero sizes (e.g. very short scrollbar thumb, it's west slice will = have=20 zero height) will be drawn incorrectly because the west SCALED bitmap w= asn't=20 created. The west slice is scaled horizontally. It's width should be al= ways=20 the same as the ORIGINAL west slice's width. So if we would like to draw a styled box correctly we should take origi= nal=20 west slice's width. (of height of the north slice). > > = so the > >=20 > > height_n or width_w is also NULL. We can count these values from ra= w (non- > > scaled) bitmaps. The values will be the same as before for common c= ases. > > And the bug will be fixed. >=20 > This looks more like a workaround for some other problem. Also while > currently width (for W) or height (for N) does not change, it may be > reimplemented in the future. In this case this patch will create hard= > to spot bug. No, this is not a workaround for some other problem. As I understand, it's the idea of the styled box - make corner slices b= e=20 constant and others to be correspondingly scaled. And sizes of the bitm= aps=20 should be correct. (e.g. widths of W, NW, SW are the same) If this conception is about to change then themes written before won't = be=20 corrcectly shown. I mean loosing of backward compatibility. I don't see how the styled box concepts are going to change... Could yo= u=20 please give an example of the concept? I still think this patch is needed and that it's correct. Maybe it should be modified to correspond some ideas. And maybe the styled box algorithms should be updated. :) Thanks for the reply! --=20 With best regards, _______________________________ Vladimir Testov, ROSA Laboratory. www.rosalab.ru