From gtk-devel Wed Dec 05 11:54:52 2007 From: Mathias Hasselmann Date: Wed, 05 Dec 2007 11:54:52 +0000 To: gtk-devel Subject: Re: Extended Layout Summary Message-Id: <1196855692.12903.51.camel () localhost> X-MARC-Message: https://marc.info/?l=gtk-devel&m=119685574804789 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1240943149==" --===============1240943149== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lSiXxZ+tL5lUjGWGgOF5" --=-lSiXxZ+tL5lUjGWGgOF5 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Am Dienstag, den 20.11.2007, 20:45 -0500 schrieb Behdad Esfahbod: > On Tue, 2007-11-20 at 20:09 -0500, Behdad Esfahbod wrote: > > On Tue, 2007-11-20 at 07:23 -0500, Mathias Hasselmann wrote: > > >=20 > > > When a container widget got more space allocated than requested, it > > > considers the difference between natural and requested size of its > > > children to distribute that additional space, in relation to the chil= d's > > > difference between natural and minimum-size. Let's use an example for > > > demonstration: > > >=20 > > > Assume we have a container with two children. Both children reque= st > > > a_min =3D b_min =3D 50 pixels as minimum size. The first child an= nounces > > > a_nat =3D 100 pixels, the second announces b_nat =3D 200 pixels a= s > > > natural size. > > >=20 > > > This gives a requested size of c_min =3D 100 pixels, and a natura= l > > > size of 300 pixels (c_nat) for the container. Now the container g= ets > > > allocated at a size of 200 pixels (c_cur). This are 100 pixels to > > > distribute (c_gap). > > >=20 > > > So the first child gets: > > >=20 > > > a_cur =3D a_min + c_gap * (a_nat - a_min) / (c_nat - c_nat)=20 > > > =3D 50 + 100 * 50 / 200 > > > =3D 75 pixels. > > >=20 > > > The second child gets: > > >=20 > > > b_cur =3D b_min + b_gap * (b_nat - b_min) / (c_nat - c_nat)=20 > > > =3D 50 + 100 * 150 / 200 > > > =3D 125 pixels. > >=20 > > Something that Ryan brought up, and I was hoping that Havoc answer is > > that the above algorithm is not optimal, you can easily do better. > > Quoting Havoc's words: "bring smaller items up to natural size first". > > Read his entire "TEXT LAYOUT THAT WORKS PROPERLY?" post here: > >=20 > > http://log.ometer.com/2006-10.html >=20 > Without checking HippoCanvas's implementation, I think this is how it > should work: >=20 > Say there are n child widgets c^0 .. c^{n-1}, let >=20 > c^i_diff =3D c^i_nat - c^i_min >=20 > We want to assign c^i_gap such that the sum of c^i_gap's is equal to > c_gap, the container's extra space to distribute. We only consider the > case that there's not enough space for all children to take their > natural size. The goals we want to achieve: >=20 > a) Maximize number of children taking their natural size. >=20 > b) The allocated size of children should be a continuous function of > c_gap. That is, increasing the container size by one pixel should never > make drastic changes in the distribution. >=20 >=20 > Goal a rules your current algorithm out as yours essentially keeps all > children off their natural size until there's enough room for all. >=20 > Goal b means that you cannot start from the least child gap, fulfill > them and then distribute the remaining gap between the rest of the > children, because when enough gap becomes available for you to > accommodate one more natural child, the allocations jump > noncontinuously. >=20 > This algorithm achieves both goals: Distribute gap to children equally > (not linearly) and not more than they need. That is: >=20 > - Sort children with decreasing c^i_diff. Use child order in the > container to break ties. I have some concerns that the sorting step changes the complexity class for some containers from O(n) to O(n log n). On the other hand we have O(n^2) in GtkTable already. So probably this doesn't hurt too much, I guess. > - Allocate like this: >=20 > for (i =3D n - 1; i >=3D 0; i--) > { > double share =3D (double) c_gap / (i + 1); >=20 > if (share >=3D c^i_diff) > c^i_gap =3D c^i_diff; > else > c^i_gap =3D ceil (share); >=20 > c_gap -=3D c^i_gap; > } >=20 So it sounds interesting to try. But as Matthias pointed out already, the use of natural size information is an implementation detail. So the question is, if I should try that variant before my code is merged. > Something completely unrelated: now that you are adding extended layout > features, should we switch to doubles or some fixed subpixel format for > size negotiation? The idea being, making it easier to make Gtk+ > dpi-independent in the future. =46rom my observation late conversion to integer values could save some pixels wasted due pessimistic rounding, which would be another advantage. Ciao, Mathias --=20 Mathias Hasselmann http://taschenorakel.de/ --=-lSiXxZ+tL5lUjGWGgOF5 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Dies ist ein digital signierter Nachrichtenteil -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBHVpGM73AS0G6kpDQRAqd1AJ0Sb5HFewXLQw+qAXukI/QjFEoNZgCfQI9e 1syTTq8SA/mFif32MTW1hQM= =nwzl -----END PGP SIGNATURE----- --=-lSiXxZ+tL5lUjGWGgOF5-- --===============1240943149== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list --===============1240943149==--