Painter's algorithm: Difference between revisions

Browse history interactively

← Previous edit

Content deleted Content added

VisualWikitext

Revision as of 15:56, 19 June 2025 edit Fluyt (talk \| contribs) Extended confirmed users 2,724 edits Corrections. Tags: Visual edit Mobile edit Mobile web edit ← Previous edit		Latest revision as of 04:41, 27 August 2025 edit undo Citation bot (talk \| contribs) Bots 5,866,664 edits Removed URL that duplicated identifier. Removed parameters. \| Use this bot. Report bugs. \| Suggested by Headbomb \| Linked from Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Sandbox \| #UCB_webform_linked 10/967
(2 intermediate revisions by 2 users not shown)
Line 26: == Advantages == ~~[[File:Dolphin_3D_engine_render.png\|thumb\|The painters algorithm is fast enough for [[Scratch (programming language)\|Scratch]] to run it well.]]~~ There are two primary technical requisites that favor the use of the painter's algorithm. Line 33 ⟶ 32: === Memory efficiency === In the early 70s, when the painter's algorithm was developed, physical memory was relatively small.<ref>{{Cite journal\|last1=Freiser\|first1=M.\|last2=Marcus\|first2=P.\|date=June 1969\|title=A survey of some physical limitations on computer elements~~\|url=https://ieeexplore.ieee.org/document/1066403~~\|journal=IEEE Transactions on Magnetics\|volume=5\|issue=2\|pages=82–90\|doi=10.1109/TMAG.1969.1066403\|bibcode=1969ITM.....5...82F\|issn=1941-0069}}</ref> This required programs to manage memory as efficiently as possible to conduct large tasks without crashing. The painter's algorithm prioritizes the efficient use of memory but at the expense of higher processing power since all parts of all images must be rendered.<ref name=":1" /> == Limitations ==