|
× [PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。 |
 |
|
AyaComicViewer 0.0.5.1 を公開します。
AyaComicVierwer 0.0.5.1 地味な修正ばかりです。 ご試用ください。 修正点はイカです。く:コミ # 内輪ねたでしたすみません。 ・基点を右上に機能追加 # 拡大時に変な動きをしますがご愛嬌で・・ ・標準ロケールを英語に、jaロケールに対応 # 英語だめすぎる・・ ・そのた細々としたバグ修正 ・画面に収まるようにリサイズするときにmaxとminを間違えていた問題 ・そのた 最近お仕事が忙しすぎてあんどろ開発どころではありません。orz やりたいこといろいろあるのに、、TT マーケットは遠いです。 |
|
|
日付からすると結構前に最新バージョンが出ていたようですね。
ちょっと忙しくて試すのが今日になってしまいました。 前にも書いたと思いますが、 Galaxy S を契約してきましたので、 Galaxy S でも試してみました。 （IS01でも試しています） 気になった点が解消されてきているように見えました。 （「基点を右上に」の動作も私的には気になるような動作には見えませんでした。 使ってる端末の速度が速いからかな・・・） チョット気になったのは 拡大で「最大ｘ２．０」設定のときに、端から端までドラッグしても 平均でｘ１．８ぐらいで止まってしまうことですね。 （指の位置の差だと思うのですが ギリギリからドラッグできるわけではないので 途中で止まってしまうんだと思います。 ｘ２．２ぐらいなら良さそうな気がしますが・・・ 最大ｘ３．０も似たようなものでした。 平均でｘ２．７ぐらいで止まってしまいます。 変動設定と固定設定を別に作っても良いかもしれません。） ちなみに Galaxy S でも IS01 と同じように 問題ない動作に見えました。 （Android2.2対応でも大丈夫そうです。）
【2010/10/31 19:17】| | サイン #553aeba30a [ 編集 ]
Re:無題
毎度ご試用ありがとうございます！
Galaxy Sですか！いいなあ！ 2.2でも大丈夫そうですね！ 報告ありがとうございます。 拡大の倍率の件ですが、わたしB型人間なので ぜんぜん気にしてませんでしたｗ かちっと2倍とかになったほうがいいですかね、、 2倍表示は簡単なのですが、操作の割り当てがきびしいです ミーヤとかPerfectViewerみたいに細かく領域を分けるべきなのか・・ 迷うとこです。 |
|
「画面に収まる設定」の修正、ありがとうございました。
Is01でも画面に収まるようになりました。 細かい点で恐縮ですが、 ページ番号の非表示もしくは表示場所を 選択できるようにしていただけると嬉しいです。 現バージョンでも、ページを切り替えてしばらくすると ページ番号の表示は消えるのですが、 連続して画像を切り替える場合、 画像サイズによっては、画像とページ番号表示が 重なることがあり、少し気になります。 勝手な要望で、すみません。 マーケット登録楽しみにしてます!!
【2010/11/03 19:06】| | 急便 #9a611b3bcd [ 編集 ]
Re:ページ番号表示
毎度ご試用ありがとうございます！
画面に収まるのバグは報告頂いたおかげで直ったようなものです！ こちらこそ、ありがとうございました！ ページ番号の非表示は次で必ず入れます！ わたしも思っていました・・これじゃまじゃね・・・？と！ マーケットがんばります！！ でもたいみんぐわかりません！ |
|
はじめまして。
少し前から使わせて頂いています。 拡大機能とか、操作性も良くてとても便利です。 お忙しそうで、開発にも時間を割けない状況はお察ししますが、少しだけ希望を書かせてください。 できれば、拡大時に「原寸」で表示する機能も追加して頂けると助かります。 現在は「拡大」は本当にバッファ内に展開している「画面ピクセル数にあわせて縮小された画像を拡大する」機能のため、縮小されてしまって潰れてしまった文字はそのまま拡大しても読めません。 拡大する時に何かの操作、または画面の特定の場所を押すような感じで「原寸表示」ができれば、文字が潰れずに読めます。 もちろん液晶サイズより大きな画像になるのでドラッグしてスクロールする必要はあります。 バッファをヒープに取っているとかなりヤバい状況だと思いますが、ダイレクトバッファなどで容量問題を回避できるのでしたら、原寸表示も追加できるのではと思います。 原寸はあくまで拡大操作の一環として、先読みなどで常に保存しておく必要までは求めません。 「原寸」操をした時にファイルから読み込んで表示するのに読み込み時間がかかっても良いです。 コミックを読んでいる時に常に原寸で見るようなものではなく、どこかのページでどうしても潰れてしまっている文字をちゃんと読みたいなどの欲求が起きた時にだけ原寸に拡大できればいい程度です。 お忙しいのでコードを検討することにすらなかなか時間も取れないでしょうか、そのうちにお暇ができてちょっと考える程度でもいいので、検討課題のストックに入れておいて頂けると幸いです。 良アプリを公開して頂き、本当に感謝しています。
【2010/11/09 09:34】| | 名乗る程ではありません #984cf551c6 [ 編集 ]
Re:原寸表示のこと
毎度ご試用ありがとうございます！
原寸の件ですが、じつは0.0.5あたりから元画像のサイズで キャッシュを持つようになっています！！ ただし、 ・画像の縦ｘ横ｘ4が5M（設定で変更可）を超える場合 ・「画面サイズによるメモリ節約を行わない」をOFFにしている場合 には画質を落として読み込まれる場合があります。 上の条件に合致しない場合には、ベースの画像は原寸で読み込まれて、 ズームの倍率によって適時縮小拡大表示されます。 画像サイズと設定を見直してみてください。 もし、条件に合致していない場合には、キャッシュ保存時のJPEG圧縮 で文字がつぶれたか、canvas.drawBitmap()の縮小・拡大精度が悪いか だと思います。 キャッシュ保存時のJPEG圧縮であからさまに画質が落ちるようなら 画質100（PNGで圧縮）を復活させてもいいかなと思っています。 # 中華PADだと遅すぎるため実用性無しと判断してはずしてました・・ 画像サイズが最大設定の10Mを超えているような場合はAndroidで 安定して読み込むには厳しい画像かもしれません、、 なんかビミョウな返事でごめんなさい。 よろしくお願いします。 |
|
お返事、ご教授ありがとうございます。
デフォルトのまま ・「画面サイズによるメモリ節約を行わない」をOFFになっていました。 ONにして、画像の展開後のサイズをぎりぎり5M以下にしたところ、ZIPファイルから読み込むとout of memoryで画像表示できなかったり、「不正な処理…」メッセージが出て突然落ちする場合が多いです。 フォルダに展開したjpeg画像(展開後サイズ5M以下)を読み込む場合はメモリー系のエラーはほとんど起きません。 5M以上に設定すると・・・ほとんど落ちますね(^^; 本体メモリーが128Mなのも原因でしょうか。256M以上の機種だと落ちないですか？ ほとんどの方にはムダな機能になるかもしれませんが、「先読み」や「前に読んだ画像のキャッシュ」をせずに、メモリーを現在表示中のページに多量に割り当てることで、5M以上の画像を読み込んでも落ちないような選択ができると、高画質の画像を読めて良いかもしれません。 反面、先読み無しなのでページめくりのたびにデータ読み込みを行うので、スピーディーさは無くなりますが、それはその選択肢を設定で選んだ人の好みの問題として・・・・。 ほかのビューワーのように、キャッシュ無しでいちいち読み込む場合は画面上に読み込み中アイコンが出て回っているとか、表示があれば人間のストレスは軽減できるので、あくまでとてもお暇があって、そういう方向性の人にも使いやすいような機能を盛り込む事にご賛同頂ける場合には、開発の方向性の１つとして考えてみて下さい。 あと、カラーモードでは無くモノクロモードで作成したjpg画像を展開しようとすると、5M以下になるはずなのにメモリー不足で落ちる事が多々あります。 jpeg展開ルーチンに何を使われているのか判りませんが、モノクロモードの場合何か余計にメモリーを消費している事は確認されていませんでしょうか？ ・5M以下(約960×1300pix以下)の画像しか対応しない ・Androidなのでメモリーの取り扱いが・・・ という条件に適わないなら、今のままでもこのビューワー用にデータを縮小した低画質のものを毎回用意すれば済む事なので、使用者側の努力と根性で乗り切ります。 自分も技術系(非Android)なので、ホイホイと開発で対応できないのは理解できます。 現状でもほかのコミックビューワーよりずっと使いやすいので、開発と公開して頂きました事には本当に感謝しています。
【2010/11/12 16:35】| | 名乗る程ではありません #986e0b8a2f [ 編集 ]
Re:Re:原寸表示のこと
zipでだけエラーが起きる場合
http://code.google.com/p/android/issues/detail?id=4489 これにあたっているかもしれません、、 ZipFileから作れるInputStreamをCheckedInputStreamでくるんだら 出なくなった（でにくくなった？）ので解決扱いにしていました。 とはいえライブラリのバグなのでなかなかどうしようもありません orz モノクロは試していませんでした、、 ただ、モノクロの場合も1ピクセル2バイト(RGB_565)で読み込まれるので 単純にモノクロでbitmapに展開したときよりも多くメモリを食うはずです。 jpeg展開もAndroidの標準ライブラリを使っているので展開のバグだったり するともうどうにもなりません orz 先読みを止めれば先読みで展開してネイティブ領域に追い出すときの メモリが節約できますね。理屈では表示させる画像にいまの2倍メモリが つかえます。 が、プログラムがへたっぴでいい感じのすぱげてーが茹で上がっている ため、なかなか直せないかもです、、 またもやなんかビミョウな返事でごめんなさい。 よろしくお願いします。 |
|
|
|
|
|
トラックバックURL
|
|