Просмотр полной версии : Варианты реализаций фотогаллерей
Я не спрашиваю КАК мне запрограмить галерею, а спрашиваю СОВЕТ какой вариант алгоритма реализации лучше! Даже алгоритм реализации не самой галереи а отображение маленьких картинок. У нас Есть список ссылок на картинки, количество файлов больше чем мы можем сразу отобразить (нужен скролинг)
1 Вариант
создаем жестко заданное количество контейнеров которые будут сразу видны загружаем в них картинки, при скроле в них же грузим новые картинки. (получаеться контейнеры остаються они и те же и содержимое меняеться)
2 Вариант
создаем сразу контейнеры по количеству всех картинок грузим туда картинки и прячем ненужные(неотображающиеся) контейнеры под маской/инвизом и прочее.
теперь мои мнения, плюсы и минусы этих двух способов
1 вариант
плюсы - мы можем хавать огромное количетсво картинок не перегружая флеш (количесво реально загруженых картинок==количество для отображения)
минусы - при каждом скроле приходиться подгружать картинки %( при плохой связи не удобно, немого тормозим в отображении
2 вариант
плюсы: у нас есть все загруженые картинки. мы не не далаем никаких
телодвижений кроме как прокрутки контейнеров.
минусы: много картинок - большая нагрузка на флеш!
меня интересует какой вариан выбрать/реализовать, и ваши советы, может новые варианты алгоритма
KidsKilla
27.12.2005, 15:26
картинки должны подгружаться по мере необходимости. 100%.
кол-во контейнеров (мувиков) увеличивается по мере роста кол-ва картинок.
если критично, можно их удалять и снова создавать по мере необходимости, благо пикчи уже в кеше и подгрузятся быстро.
1 вариант дает больше возможностей.
2 вариант ограничен количеством картинок.
Минус 1 варианта будет незначительным, если уменьшить вес картинок, и подгружать следующие заранее, пока предыдущие просматриваются.
Но не исключены варианты, когда 1 вариант может оказаться выгодней, конечно же все зависить от условий.
Второй вариант лучше. Но грузить надо не всё сразу а по мере необходимости. Ну и не хранить всё, а хранить допустим разделами. При переходе в другой раздел старый очищаеться. А контейнеры -- это всего лишь пустые мувики. :)
Второй вариант однозначно лучше, а что касется грузить сразу все или по очереди или по мере небходимости зависит от размера картинок и их количества, галереи бываю очень разнообразные и не только по структуре но и по дизайну, поэтому тут нужно выбирать ...
ну тогда более конкретно
галеерея - 100 картинок,
есть ссылки на мелкий вариант(для контейнера)
и на большой - для увеличения.
мелкие картинки (по идее) размером 100х100 пикселей ну все равно нужно контролировать их размер, если не вписываються то уменьшать пропорционально по размеру.
второй пример количество картинок - 1000 %))
Вот 2 вариант (http://www.hot.ee/ipgraph/photos). За дизайн не пинать. Движок тестирую. Сейчас делаю 1. Думаю так: если фоток немного... где-то до 40, то 2 вариант неплох. Видно всю галерею, свобода выбора, скролл невелик и т.д. Если же фоток поболее, то лучше, по моему 1 вариант, со вставленными ссылками на слайдеры с ограниченным количеством кадров. Здесь можно обойтись без скроллинга, просто грузим столько превьюшек, сколько влезет в отведенное им место, ограниченное дезигном, например.
самый грамотный вариант ;)
_http://www.imagevuex.com/imagevue
самый грамотный вариант
http://www.imagevuex.com/imagevue
хороший пример, его функциональность то мы и обдерем %))
так это и есть твой первый вариант как раз )
Вот хоть убейте меня не пойму чем второй вариант лучше?!
А если там в самом деле несколько сотен картинок? Столько трафика, не спросив -- да я б автору руки пообрывал 8)
На мой взгляд, можно совместить варианты и сделать что-то типа:
Грузим число картинок по числу видимых сразу контейнеров,
после чего сразу следующие столько же картинок, которые
лежат в контейнерах за предалами видимости (под маской).
И так далее, по мере скрола.
"Просмотренные" контейнеры, конечно же удалять нужно.
То есть, если пользователь не будет листать картинки с
сумасшедшей скоростью, то всё будет происходить для него
"прозрачно" как будто все картинки подгружены. И траффик
он будет контролировать сам.
nyctota:
а если 'буфернуе' контейнеры не догрузятся ? юзер дернет и они начнут снова грузиться в новых контейнерах, в 'буферных' будут новые шрузиться, а потом снова дернет скролл )
вот тебе и трафик.
делать просто потранично и все. имхо.
WD`:
Ну скролл то можно убрать, пока не подгрузился 1 блок буф. (невидимых) контейнеров. А после, пусть себе дергает - кэш рулит.
to WD`:
Можно и постранично. но так приятнее))
to MOHCTEP:
Да, именно так и нужно делать, чтоб пользователь своими ручонками ничего не натворил раньше времени))) Шутка.
На самом деле такая маза не совсем катит, имхо, так как пользователю придется ждать загрузки ВСЕХ картинок ДО той, которая ему могла быть нужна (вот знает он, положим, что хочет посмотреть именно фотку номер 123 и все тут))).
Хотя это решаемо кнопкой "перейти на сраницу № ..."
Вобщем, реализую, проверю — видно будет. А чисто теоретически, на мой взгляд, самый приемлемый вариант... пока...
Кто еще какие предложит?
В принципе, 1 вариант лучше,и я его уже сделал %)) осталось токо мелочи доделать типа зума и пр.
что хочет посмотреть именно фотку номер 123 и все тут))).
это удобно реализовали в примере Ieshua %)).
этот пример почти отвечает нужными требованиям (нужно чуть больше функциональности).
второй вариант отпал - т.к. юзер не может долго ждать %(( да и по памяти пребования у него намного выше, а если такая галлерея попадет в руки дубовых пользователей с возможностями добавлять картинки то совсем худо будет %))
to nyctota:
Можно кнопарей натыркать, по кол-ву предполагаемых, но еще незагруженных контейнеров. В хинтах кнопок указать диапазон фоток для каждой и убивать кнопки, по мере автоподгрузки контейнеров.
to nyctota:
Можно кнопарей натыркать, по кол-ву предполагаемых, но еще незагруженных контейнеров. В хинтах кнопок указать диапазон фоток для каждой и убивать кнопки, по мере автоподгрузки контейнеров.
ну, да. я так и сказал :D
*только не по числу контейнеров, а по числу страниц с контейнерами ;)
В принципе, 1 вариант лучше,и я его уже сделал %)) осталось токо мелочи доделать типа зума и пр.
...
Покажешь? :D
Да, как доделаю мелочи %))
to __i:
Очень интересно посмотреть, ждем-с:D
to nyctota:
Именно контейнеров, ведь разговор был о скроллируемом превьювере. Почто страницы плодить? Иль я не допонял чего? В голове ишшо туман некоторый после НГ. :-)
Вот, отличный пример паттерн-основанной галереи (http://forums.ultrashock.com/forums/showthread.php?s=&threadid=76251), с рассказом о создании в деталях. Маст-рид.
Читал, не успел посмотреть внутренность т.к. на работе нету 8 флеша %((, но успел скачать исходник и потестить то что там было откомпиленное - однозначно такой вариант отпадает. При количестве картинок 300 тормозит шо бешеная пока все картинки не догрузит , а как догрузит то через раз притормаживает (а машинка то у меня де самая гавеная - цел 2.93, 512мб) !!!, загрузки 600 я так и не дождался. Это с учетом что все грузилось локально ,а юзера такой же трафик убьет сразу на повал, да надоест ему ждать пока машина раздуплиться!
Конечно со стороны ООП, (как это описано на форуме) все очень красиво, вдохновлен%))
to __i:
Очень интересно посмотреть, ждем-с:D
to nyctota:
Именно контейнеров, ведь разговор был о скроллируемом превьювере. Почто страницы плодить? Иль я не допонял чего? В голове ишшо туман некоторый после НГ. :-)
Что значит "скроллируемый"?
Я рассматривал первый вариант __i в качестве основы. Сказано: "создаем жестко заданное количество контейнеров которые будут сразу видны ...".
Я понял так, что это контейнеры на условной "странице" (видимой области). Т.е. при нажатии на кнопку "next" осуществляется как бы переход на следующую страницу, на которой такое же кол-во контейнеров со следующей партией картинок. Поэтому я и говорю про страницы.
Повторяю, что "страница" -- это не новая HTML-страница, а видимая область флэшки с контейнерами на ней. И ощущение того, что произошла смена страниц, передается только посредством смены изображений в контейнерах и, возможно, какими-то эффектами перехода.
Работает на vBulletin ® версия 3.7.3. Copyright ©2000-2026, Jelsoft Enterprises Ltd. Перевод: zCarot
Copyright © 1999-2008 Flasher.ru. All rights reserved.