【Java標準GUIライブラリ】 JavaFX スレッド

**デフォルトの名無しさん** · 2014/07/05(土) 01:27:45.85

JavaFXについてのスレッドです

**デフォルトの名無しさん** · 2018/11/10(土) 16:06:08.57

scene builder最初使おうとしたけど結局コード直接書く方が楽だな
細かい事やろうとしたらコード書かなきゃならんし、全部コードでやる方が良い

**デフォルトの名無しさん** · 2018/11/10(土) 16:35:27.27

mavenでfxを入れると
開発環境のプラットフォーム用のライブラリがDLされる？
ここではwinライブラリしか出てきていない。
https://skrb.hatenablog.com/entry/2018/07/25/220530

ここもwinライブラリしか出てこない。
https://seraphy.hatenablog.com/entry/2018/07/27/175105
＞maven-dependency-plugin で依存jarをmodsフォルダに出力するようにしているので、
この処理で依存ライブラリだけを見てるからか？

開発環境と異なるビルドをする方法はあるんだろうか。

**デフォルトの名無しさん** · 2018/11/10(土) 19:44:58.73

>>304
OCAにサインしてOracleに無償の献身を誓った個人開発者、だぞ
今の体制のままならOracleが完全に手を引いたら絶対に確実に間違いなくJavaFXは消滅する

**デフォルトの名無しさん** · 2018/11/10(土) 19:57:35.54

https://aoe-tk.hatenablog.com/entry/2018/03/18/185144

この記事によると今後も大丈夫みたいに書いてあるけど

どうせどの言語もライブラリもプロジェクト消滅とか停滞のリスクはあるんだし
俺は今後も使うよ

**デフォルトの名無しさん** · 2018/11/10(土) 20:23:43.23

フリーなのが救いだな。誰もメンテナンスしなくなっても最悪自分でなんとかできる。できなくてもできる人にやらせる事が可能かも知れない。金掛かるかも知れないがな。
ブロブライエタリだど握りしめられたまま死なれたら終わりだ。本当に二度と使えなくなる。

**デフォルトの名無しさん** · 2018/11/11(日) 15:02:28.34

>>307
Oracle完全撤退後は、もはや何もコミットしてないOracleに対して何故かソースを寄贈し続けなければならない謎プロジェクトになるんだぞ
そんなものに進んで協力する奴がいたらよほどのドMだな
OCAを廃止しない限り、OpenJFXはどう転んでもコミュニティプロジェクトとして成立し得ないよ

**デフォルトの名無しさん** · 2018/11/12(月) 22:48:59.70

openjfx本家死んでもgluonのhard forkに開発者移るだけだろう。
サポートされるデバイスが増えるだけ。

**デフォルトの名無しさん** · 2018/11/13(火) 06:17:45.59

>>311
そのGluonの収入基盤がまた不安なんだよね。Gluon Mobileで開発なんて話まったく聞かないし。
表に出てこないだけで、それなりに売り上げているんだろうか。

**デフォルトの名無しさん** · 2018/11/13(火) 08:44:59.29

Gluonは囲い込んで金取ることばかり考えてて時代錯誤な印象だわ
元々JavaFXにタダ乗りしてXamarinの劣化コピーを作ろうとしてただけで自分達で積極的にJavaFXコアの開発を推進する気はなさそうだし
現状のまま売り逃げして終わりだろうな
こんなものに期待するくらいならJava to .NETコンパイラでも作ってXamarin使ったほうが遥かにマシだな

**デフォルトの名無しさん** · 2018/11/25(日) 10:34:22.08

>>313
Gluon はどうやって収入を得ればよかったんだろうか。

**デフォルトの名無しさん** · 2018/11/25(日) 11:14:37.59

そもそもビジネスモデルが間違っているからどうやってもダメだよ
モバイル向けの開発ツールキットはあくまでプラットフォームビジネスの付属品であり、単独では商売として成立しない
この手の最大手であったXamarinですらダメだったのに、なぜそれよりあらゆる面で劣るオモチャで儲けられると思ったのか

**デフォルトの名無しさん** · 2018/11/25(日) 11:37:10.53

>>315
JavaFXにはどうあがいても絶望しか残されていなかったということか。
得をしたのは開発中止という格好悪い方法を避けて体よくJavaFXを捨てることが出来たOracleだけか...

**デフォルトの名無しさん** · 2018/11/25(日) 15:24:07.23

クライアントサイドもできたほうがJavaユーザー増えると思うんだけど
JavaFX自体は良い感じ

**デフォルトの名無しさん** · 2018/11/25(日) 15:49:56.84

反例 : 過去20年のJava
まあ、よく頑張ったよ
もう楽にさせてやろう

**デフォルトの名無しさん** · 2018/11/26(月) 06:18:29.70

でもクライアントサイドが作れませんとなったら
新たにプログラミングを学ぶ人が選ばないと思う

**デフォルトの名無しさん** · 2018/11/26(月) 06:42:07.93

>>319
プログラミング必修化で、業務でなく趣味でプログラミングする人も増えるだろうけど、
確かに趣味でやるにはWebフレームワークでGUIというのは負担が重すぎる。
かくいう自分も趣味でJavaFXから入ったくち。

**デフォルトの名無しさん** · 2018/11/26(月) 11:13:55.60

確かに趣味でやるのにGUIがやりにくいでは
選ばれにくくなるだろうな

やっぱWindowだしてやりたいもんなあ

**デフォルトの名無しさん** · 2018/11/26(月) 21:40:59.64

FXもやってくぞー

**デフォルトの名無しさん** · 2018/11/27(火) 01:10:49.38

xamarinxamarin言ってるやつは何しに来たんだ？xamarinが最大手？馬鹿抜かせ。
日本以外の世界の水道・ガス・パーキングメーター類、ハンディPOS、中身組み込み向けjavaだぞ。
BD-Jもjavaだしxamarinどこにあるんだよ。

gluonに間違ってるところがあるとしたら組み込みにjava seベースとその上で動くjavafxを選んだことだろ。
組み込みじゃフットプリントでかすぎるし、リソース食い過ぎるし、
組み込みにRIAみたいないちいちアニメーションするguiも必要ない。
そういうのは富豪環境のエンドユーザー向けでやればいい。
xamarinと被る領域なら最近は組み込みまでnodeじゃん。

**デフォルトの名無しさん** · 2018/12/01(土) 06:57:32.19

>gluonに間違ってるところがあるとしたら組み込みにjava seベースとその上で動くjavafxを選んだことだろ。
GluonはJavaFXするための会社だから、存在を全否定するのはやめて差し上げろ。

**デフォルトの名無しさん** · 2018/12/01(土) 07:49:15.91

FXやりたいんじゃなくて、やりたいのは金儲けでしょ
そもそもGluonってJavaFXにタダ乗りしてXamarinモデルで一儲けしようとしてただけで、
JavaFXの本体の開発を進めるなんて全く言ってないし実際やってもいないのに的外れもいいとこ

**デフォルトの名無しさん** · 2018/12/01(土) 08:39:40.60

>>325
一応JavaFXに関する貢献でDukes Choice Award を2015年に取っているから
何もしていないということはないと思うが、
GluonにJavaFXの開発をする体力はないだろうという点には同意する。

**デフォルトの名無しさん** · 2018/12/01(土) 09:04:01.42

筋違いの期待をしてる人には気の毒だが、そもそもGluonは本体はオープンソースですらない
別にGluonを非難する意図はないぞ
そこらへんのたかが一中小企業に対して、どう頑張っても自社の独占資産にならないGPLソフトウェアに全力投資しろというのは無茶な話だ

**デフォルトの名無しさん** · 2018/12/01(土) 17:51:44.63

話題にしたいのはGluonが金儲けをするためにはどうするべきだったかではなくて、
JavaFXが安定して発展するにはGluonがどうすればよかったかなのだが、
>>316で言ったように最初から無理ゲーだったということでおk?

**デフォルトの名無しさん** · 2018/12/13(木) 18:43:00.51

ニコニコ大百科での暗躍も実を結ばなかったな

**デフォルトの名無しさん** · 2018/12/13(木) 18:43:26.32

JavaFX
https://dic.nicovideo.jp/a/javafx

**デフォルトの名無しさん** · 2018/12/13(木) 19:03:43.75

>>329
ごめん、言いたいことがわからない。

**デフォルトの名無しさん** · 2019/01/17(木) 20:38:34.91

ニコニコ大百科見てないなら黙ってりゃいいのにでしゃばりかｗ

**デフォルトの名無しさん** · 2019/01/17(木) 20:40:57.32

>>331
言いたいことわからないとか本気でいってんのかよ
そんなんだから普及しないんだよバカ

**デフォルトの名無しさん** · 2019/01/18(金) 10:53:22.72

>>333
>>331が>>329の言いたいことがわからないことと、JavaFXが普及しないことに因果関係はないと思うんだけど。
>>333の頭の中身は大丈夫なのでしょうか。

**デフォルトの名無しさん** · 2019/01/18(金) 23:19:24.49

何かと戦ってるんだろうなぁ

**デフォルトの名無しさん** · 2019/01/21(月) 10:54:21.77

いや>>333のバカってのはいわゆるツンデレというやつだろう。

**デフォルトの名無しさん** · 2019/01/22(火) 19:01:58.84

>>334
言いたいことがわからないっていってるんだから因果関係もない
お前の頭が大丈夫なのか
そもそもJavaFXの関係ある話なの？

**デフォルトの名無しさん** · 2019/01/22(火) 19:02:31.24

JavaFXのスレでなに期待してんだろうなこのバカ

**デフォルトの名無しさん** · 2019/01/22(火) 19:03:29.26

>>336
ごめん、言いたいことがわからない。

**デフォルトの名無しさん** · 2019/01/22(火) 19:05:16.91

>>334
わかったから
ニコニコ大百科での暗躍も実を結ばなかったな
JavaFX
https://dic.nicovideo.jp/a/javafx

で
何がいいたいかくらいわかれバカ

**デフォルトの名無しさん** · 2019/01/22(火) 19:06:08.10

ニコニコ大百科での暗躍も実を結ばなかったな
JavaFX
https://dic.nicovideo.jp/a/javafx

**デフォルトの名無しさん** · 2019/01/23(水) 09:38:21.37

暗躍？

**デフォルトの名無しさん** · 2019/01/23(水) 18:32:57.39

>>337-341
うわぁ…

**デフォルトの名無しさん** · 2019/01/30(水) 12:40:06.37

>>343
うわああ・・・やばこいつｗｗｗ

**デフォルトの名無しさん** · 2019/01/30(水) 12:40:25.00

>>342
暗躍じゃなきゃなんだよ

**デフォルトの名無しさん** · 2019/01/30(水) 12:40:45.17

>>342
ごめん、言いたいことがわからない。

**デフォルトの名無しさん** · 2019/01/30(水) 12:41:13.38

>>335
ごめん、言いたいことがわからない。

**デフォルトの名無しさん** · 2019/01/30(水) 12:42:08.59

>>343
ごめん、言いたいことがわからない。

**デフォルトの名無しさん** · 2019/01/30(水) 12:48:50.40

煽りだけは一人前なんだから嫌なんだよ
クズが！

**デフォルトの名無しさん** · 2019/02/04(月) 18:14:04.34

スレ伸びてるやん！

**デフォルトの名無しさん** · 2019/02/05(火) 09:40:56.91

JavaFXの人気に嫉妬

**デフォルトの名無しさん** · 2019/02/05(火) 22:09:37.36

>>350
言いたいことあるなら言ってみろ？オラ
ゴミレスしやがって

**デフォルトの名無しさん** · 2019/02/05(火) 22:09:56.80

>>351
マジレスするけどJavaFXの人気ないでしょ

**デフォルトの名無しさん** · 2019/02/05(火) 23:26:20.93

そもそも次スレ立つかどうかもわからんけど
次は標準が外れるんだな(´・ω・`)

**デフォルトの名無しさん** · 2019/02/06(水) 06:46:34.91

>>354
JDK11からなので、もう外れているとも言える。

**デフォルトの名無しさん** · 2019/02/06(水) 08:38:39.25

誤解した。スレタイから標準の文字が外れるという意味か。

**デフォルトの名無しさん** · 2019/02/06(水) 15:16:17.92

俺の心の中では永遠に標準

**デフォルトの名無しさん** · 2019/02/09(土) 14:39:10.08

伸びてるから期待してみたら・・・
まったくぅ

**デフォルトの名無しさん** · 2019/02/09(土) 15:50:05.38

流行らせれば良いんだよ。そうすればデファクトスタンダードになってやがてISOとかに登録されて標準化される。

**デフォルトの名無しさん** · 2019/02/10(日) 23:17:53.46

JDK8のJavaFX使うのむっちゃ楽だったのにな～

**デフォルトの名無しさん** · 2019/02/19(火) 05:10:46.16

>>360
まったくだ。
JDK11だとどうすれば使えるのかすらよくわからん。

**デフォルトの名無しさん** · 2019/02/25(月) 21:42:40.83

ちょっとスレチだけどいい？もしかして、Java標準のGUIってSwing？

**デフォルトの名無しさん** · 2019/02/26(火) 09:56:24.17

まあ、最初からライブラリに含まれているので標準と言えば標準かな。

**デフォルトの名無しさん** · 2019/03/02(土) 15:41:40.44

Amazon CorrettoがJavaFXをサポートしていると聞いて入れてみたが、だめだった。
色々ないものがあるらしい。
https://stackoverflow.com/questions/53876524/is-javafx-media-supported-by-corretto

**デフォルトの名無しさん** · 2019/03/31(日) 04:43:09.25

openjfx12からscenebuilder削除されたからgluonのハードフォークが名実ともにscenebuilderになったな。
プロパティファイル化けてんの直してほしいけど、今openjfxのスポンサーgluonだし、
openjfxの公式サイトがgluonでそこからダウンロード出来るのがgluonのビルドだし、
ただのミラーのはずだったgluonのportingのgithub issuesにopenjfx関連のissueあるしこのままjavafx乗っ取られたりしてなw

>>360,361,364
9以降にopenjfxの適当なdistroのモジュールパス通すだけよ。
gluonのsdkでも自分でビルドしてもビルドツール使ってもjavafxバンドルしたjre作っても何でも良いよ。
非モジュールのjavafxアプリをhogehogeするよりモジュール化した方が簡単。

**デフォルトの名無しさん** · 2019/05/14(火) 04:11:54.09

corretto8入れて解決
足りないものがあるなら言えば入れてくれるだろ

**デフォルトの名無しさん** · 2019/05/28(火) 12:52:24.67

>>365が言ってるのは自己完結型だな
>>366はOS共通のJDKでJavaFXやる方法

**デフォルトの名無しさん** · 2019/06/21(金) 06:10:10.33

>>366
言っても入れてもらえなかったぽい。代わりに
https://bell-sw.com/pages/java-8u212
なんてものがあるらしいが、問題は
BellSoftがマイナーすぎてOracleやAmazonほどに世間の検証を受けていないことか。

**デフォルトの名無しさん** · 2019/08/29(木) 00:33:37.84

gluonのjavafxバイナリがマイナーチェンジする気まったくないな。
SceneBuilderは自分でビルドすればいいとしてopenjfxめんどくさいのがな。
Liberica JDKはopenjfxは12みたい。11の新しいリビジョンはソースからビルドするしかなさそう。

**デフォルトの名無しさん** · 2019/09/25(水) 02:33:18.22

>>365 >>366
あのさあ・・・
JDK8時代と比べて何も違わんとか言いたげなのは明らかにおかしいだろ
そりゃ過疎るわ

**デフォルトの名無しさん** · 2019/10/23(水) 16:53:10.00

FXML使う価値ある？直接コード書いたほうが楽なんだけど

**デフォルトの名無しさん** · 2019/10/24(木) 21:46:16.93

>>371
SceneBuilderを使ってGUI上でFXMLを作成できるのが売り。
生FXMLを書くくらいならコードを書いた方が楽なのには同意する。

**デフォルトの名無しさん** · 2019/10/25(金) 15:42:06.38

でもSceneBuilderだとすぐに限界に到達するんだが・・・。
JavaFXってのは迷走してるおかしなプロジェクトなのでは。
初期の頃何か独自スクリプトがあって廃止されて、FXMLとかSceneBuilderも微妙・・・。
性能もコード資産の量もSwingのほうが上だと言われてる。

**デフォルトの名無しさん** · 2019/10/25(金) 15:43:13.24

そもそもなんでOracleはSwingを続けるんじゃなくJavaFXを始めたのか？
JavaFXはモバイル対応してるというけどSwingをモバイル対応させればよかったのでは

**デフォルトの名無しさん** · 2019/10/25(金) 21:36:02.66

>>374
どこまで本当か知らないけど、SceneBuilderみたいなGUIツールでデザインしてから
Swingのコードを生成するのは難しかった(実際にそういうツールはあるが不安定)
ので、XMLを導入することにしたとか聞いたことがある。
また、SwingにはBindingとかのReactive Programmingのような仕組みがない。

Swingもそれほど使われていなかったから、この際パラダイムごと更新してしまおうと思ったら
Swing以上に使われなかったというオチがついてしまった。

**デフォルトの名無しさん** · 2019/10/26(土) 08:24:20.30

プロパティバインド使うとモデル側コードにStringPropertyとかの
JavaFX関連コードが出てきて嫌なんだけど？
どこがモデルとビューの分離なの？
それでどうやってビューを別のGUIフレームワークに自由に切り替えれるの？

**デフォルトの名無しさん** · 2019/10/26(土) 13:30:57.74

それはモデルじゃなくてライブラリが受け持つ話では？

**デフォルトの名無しさん** · 2019/10/26(土) 13:44:16.28

例えば。
https://qiita.com/kenji-yokoi/items/5cd5f74865de7617cfb5
＞public class Model {
＞private StringProperty valueProperty = null;

https://docs.oracle.com/javase/jp/8/javafx/properties-binding-tutorial/binding.htm
＞class Bill {
＞ private DoubleProperty amountDue = new SimpleDoubleProperty();

https://gist.github.com/aoetk/4363405
＞public class Person {
＞ private StringProperty name = new SimpleStringProperty();

これらはすべてモデルにProperty系クラスが表れている。
でもPropertyはjavafxパッケージに含まれている。
モデルとビューの分離というなら、モデルをほかのGUIフレームワークでも使いまわせるように
クラス依存関係自体が分離されるべきだと思う。

**デフォルトの名無しさん** · 2019/10/26(土) 15:44:51.28

>>376
自分も同じことを感じたことがあるので、言いたいことは概ねわかるつもり。

あるClass AModelの、あるフィールドAModel#fieldについて、Javaのお作法通りにしていれば
AModel#getField, AModel#setFieldをObjectPropertyを使って書けば、
AModelを継承したObserveableなModelクラスが出来上がるということなのかなと
解釈してそれ以上は考えないようにしている。

多分GUIフレームワークをJavaFXに一本化することを目標に開発されたので
他のGUIフレームワークでModelを使いまわすことは考えられてない。
Model作成の段階で最初からPropertyを用いるという前提だろうとは思う。
最初にも書いたように、他のライブラリやフレームワークと組み合わせようとすると
障害が大きいことには同意する。

**デフォルトの名無しさん** · 2019/10/26(土) 15:57:08.47

JDKを作ってる人達なら
任意のオブジェクトの状態変更を監視するように作ることもできたんじゃないか？
オブジェクトの状態が更新されたらGUIも更新、
更新頻度が激しすぎるといけないから最速でも１秒に１回、とか。

それにしたってDB上で更新が発生したらどうするのかと思うけど。

**デフォルトの名無しさん** · 2019/10/26(土) 17:16:43.97

>>380
できたとは思うけど、OptionalをObjectのスーパークラスにしなかったくらいだから、
そんな変更はできたとしても言語コンセプト的にもしなかっただろうと思う。
JavaFXがOptional以上に大事なものであればあるいいは...ないか....

DB上で更新検出はJavaFX以外でも難しそう。

**デフォルトの名無しさん** · 2019/10/26(土) 17:24:54.18

プロパティバインドというアイデアは永続化されないモデルでだけ有効。
ゲームアプリならありそうだけど普通のアプリでは無さそうな気がする。

DBからオブジェクトを読み出す場合、読み出した時点のデータのまま変化しないし。
変化を検出できるのはもう一度DBから読み出した時だ。

最初独自スクリプトがあって廃止されて、プロパティバインドも微妙。
SceneBuilderやFXMLは一部の人達は使ってるのか知らんが俺には良さそうなものに思えないし。
JavaFXを設計してる人達の構想力まで怪しく思えてくる。

でもなぜかJavaFX好きではあるんだけど。

**デフォルトの名無しさん** · 2019/10/27(日) 05:06:45.01

>>382
SceneBuilderはとっつきやすくて配置の微調整をやりながら構成するのに便利だったけど、
FXML内で反復(及び分岐)をしようとしたときと、動的に数値を変更しようとした時には絶望しか無いことには同意する。
まあ、コントローラー側と組み合わせてなんとかした。

プロパティバインドは、自分はゲームじゃないけどMVCで使っているうちにMVVMを再発明したw

**デフォルトの名無しさん** · 2019/10/27(日) 23:17:14.16

mvvmfxというライブラリなかったっけ？

**デフォルトの名無しさん** · 2019/10/27(日) 23:29:18.97

>>384
ありがとう。でもまだそれが存在しない頃の話だったんだ....

**デフォルトの名無しさん** · 2019/10/29(火) 22:17:46.91

JavaFXが分離されてしまった今
JavaのGUIアプリは何を使うのが正解なのだろうか

**デフォルトの名無しさん** · 2019/10/30(水) 09:33:41.93

awt

**デフォルトの名無しさん** · 2019/11/03(日) 22:40:42.80

時代はswt

**デフォルトの名無しさん** · 2019/11/06(水) 21:42:11.63

javaFXじゃなきゃやだぁ

**デフォルトの名無しさん** · 2019/11/07(木) 11:48:57.39

遠慮なくどんどん使ってください

◆JAVA/drQNg · 2020/02/25(火) 02:51:55.03

JavaSEから外したのは残念

◆JAVA/drQNg · 2020/02/25(火) 02:52:38.11

>>388 swtてPureJavaでしたっけ？

**デフォルトの名無しさん** · 2020/02/26(水) 01:35:11.58

自分で配布するjarファイルとかにはJavaFX含めても良いんだよな？
まあ多分俺はしないと思うが。

**デフォルトの名無しさん** · 2020/02/29(土) 21:47:18.51

>>386
Swingがあるじゃないか

**デフォルトの名無しさん** · 2020/05/04(月) 23:29:15.43

気晴らしに昔の話にレスしよう。

>>373
>性能もコード資産の量もSwingのほうが上だと言われてる。
newt並に低レベルなウィンドウ周りとレンダラのパイプラインが一段少ないからそれはないと思う。
ハードウェアもPS世代と固定機能世代だし。

>>374
>Swingをモバイル対応させればよかったのでは
初めからjava meで動く。CDC+AGUIでswing含む。

>>375
>また、SwingにはBindingとかのReactive Programmingのような仕組みがない。
SwingLabが開発しててJSRもあったけどsunがjavafxに注力するから全部白紙になっただけ。
SwingApp framework, beans binding, timing framework, SwingX, JMediaは白紙後全部javafxで同じアイディア実現したよ。
swing teamが協力したし。
swingにないのはコレクションベースのプロパティくらいかな。

**デフォルトの名無しさん** · 2020/05/08(金) 05:37:03.88

JavaFXすごいなUIスレッドと別に描画スレッドがあるのか（WPFと同じ）
Swingでは描画もUIスレッドで行われていたから独自描画とか重いことするとキーイベントやマウスイベントが遅延してた
これがアプリが重いと言われる原因になることも多かったと思う

JavaFXでは描画スレッドが分離したおかげでUIスレッドが軽くなった
ただし中途半端な状態が描画されることもあるので実装には注意が必要
・スタイルクラス.blueを外す
・スタイルクラス.redを付ける
これだと色が青から赤に変わる前に一瞬デフォルトカラーが見えてしまうことがある（もちろん変更はUIスレッドでやってる）
・スタイルクラス.redを付ける
・スタイルクラス.blueを外す
といった工夫が必要

**デフォルトの名無しさん** · 2020/05/08(金) 05:43:58.65

トランジション・アニメーションが描画スレッドだけで完結できないのが残念
プロパティ更新自体はUIスレッドで行われるから
マウスイベントハンドラなんかで重い処理をするとアニメーションがガタつく
結局、プログラマーが適切に非同期処理を実装しないといけないんだなあ

**デフォルトの名無しさん** · 2020/05/08(金) 11:12:02.25

SwingでもEDTで重い処理すんなってのは常識だと思ってたけど……
SwingUtilities#invokeLater(Runnable) とか……

**デフォルトの名無しさん** · 2020/05/08(金) 12:21:07.75

ビジネスロジックをワーカースレッドで実行するのは当然分かってるよ
それでもUIスレッドでしかできないことってあるのよ

**デフォルトの名無しさん** · 2020/05/30(土) 02:21:06.70

描画スレッド=UIスレッド＝FXスレッドじゃないの？
描画スレッドとUIスレッドを別のものとして喋ってるのが良く分からん。

https://docs.oracle.com/javase/jp/8/javafx/interoperability-tutorial/concurrency.htm

トランジションあたりは良く調べてないけど、
その辺がスムーズに動かないならJavaFXベースのゲームエンジンは無謀なのかな。

**デフォルトの名無しさん** · 2020/05/30(土) 06:53:55.51

JavaFXではUIスレッドとは別に描画スレッドがあるのよ
これがSwingとの大きな違い
UIスレッド＝FXスレッド
描画スレッド＝Prismスレッド

WPFも同様にUIスレッドと描画スレッドを持つGUIツールキットだ

**デフォルトの名無しさん** · 2020/05/30(土) 08:14:38.00

javafx+3dで描画軽くする方法ありますか？
大量にshape3dを表示すると重くて重くて
オクルージョンカリングなるものを実装しようにもjavaでの実例が見つからず厳しい

**デフォルトの名無しさん** · 2020/05/30(土) 08:47:50.17

やりたいことはこのように複数のBoxを組み合わせていきたい
https://imgur.com/p1mGbkc.png
ただ通常のBoxでは枠線が表示されないため現状１つのBoxにCylinderを12本くっつけて枠線として表示してる
他にはRectangleを６つ組み合わせて面表示しない方法
テクスチャ―を張り付けてそれっぽく見せる方法を試したけど今のところ一番良かったのがCylinderの手法
普通のBoxとワイヤーフレームを合体させる方法が一番軽量なんだけどTriangleMesh(三角形メッシュ)になってしまって見栄えが悪いのでNG
https://imgur.com/X6VrMC7

現状解決方法としてTriangleMesy→RectanleMeshにする
オクルージョンカリングを実装する
の２つが解決方法として考えられるがどっちも参考例がなくて厳しい

他の案でこんなのしたら解決できるのでは？とかこの案はこうすれば実装できる！とかあったら教えてほしい
質問スレチだったらすまん

**デフォルトの名無しさん** · 2020/05/30(土) 10:36:51.70

swing vs javafx自分の理解

メリット
・CSS
・prism。UIスレッドと分けられていて描画が停止しない。GPUが活用される。
・ラムダベースのAPI
・Scene Builderがある（個人的に便利と思わない）

デメリット
・バグが多い
・モデルとビューの分離がし辛い。StringPropertyとか使わない方が良さそう

その他
・ゲームエンジンも通常のGUIもjavafxで一本化できるかも
・標準から分離されたが、JDKと同じ範囲でサポートされるのか？